Rails cheerleaders: go easy on the hyperbole

perrin on 2005-10-19T16:59:40

This is from the first page of the latest Ruby on Rails article on the O'Reilly website:

"In this short time, Rails has progressed from an already impressive version 0.5 to an awe-inspiring, soon-to-be-released version 1.0 that managed to retain its ease of use and high productivity while adding a mind-boggling array of new features."

Come on! I don't know Curt Hibbs, and I have nothing against him, but this intro is positively ludicrous. How is this supposed to be "awe-inspiring?" Does he think that before Rails we had no object/relational mappers, no code generation, no MVC, no test scripts, no dynamic languages? You'd have to ignore an awful lot of web development tools (that pre-date Rails) to think that.

But he does seem to think that. A little further down the page he says this:

"The typical development cycle for testing a change to a web app has steps such as configure, compile, deploy, reset, and test."

In what world is that "typical"? The only web development tool in use these days with a compile step is Java, and if you look at web development as a whole, there are more people NOT using Java than using it.

It's also not a very accurate list. Even Java apps don't require reconfiguration every time you change your code! And Rails doesn't remove the "test" step.

Most of the writing about Rails that I've seen seems to have blinders on when it comes to anything other than Java. It would be nice to see some acknowledgment that other dynamic languages already have this stuff, and a little more touch of reality in general. The current tone smacks of ego and arrogance. I don't see anything wrong with trying to draw in Java converts, but if the plan is to just ignore PHP, Perl, and Python, they're losing out on an awful lot of potential allies.

---

My guesses ...

autarch on 2005-10-19T19:07:36

I've found the whole Rails thing pretty silly myself. It looks like a very nice tool for certain apps, but I really don't think it'd help much at all for apps with complex, large databases, for the same reason I don't think Class::DBI works well for in those cases.

My guess as to why Rails is so hot is several-fold:

- The folks using it make very pretty products. Basecamp looks great, as does the Ruby on Rails site. I wish Perl sites and apps looked that good, and I really wish mine did!

- If you've been using PHP or Java, I think a nicely designed all-in-one kit like Rails that makes building small to mid-sized database-backed webapps is going to be a huge productivity boost.

- People coming from PHP or Java, which AFAIK have no similar toolkits, are going to be wowed. Ruby had nothing like it before Rails. Perl has Catalyst or Maypole, but they're Rails imitators, so there's really no reason to use them unless you already know some Perl. If you do, they'll probably serve you as well as Rails. Not sure if Python has anything like it at all.

- Ruby is a cleaner language than Perl, no doubt. Honestly, I'd've jumped ship if it had CPAN. It's very easy to read at first glance.

But of course, if like you and I, you've worked on a number of really large web apps, you look at this stuff and wonder what all the fuss is about. But remember, most people probably haven't. If you've done a lot of small apps by hand, then doing them with Rails will be much easier. Once you go to do something bigger and more complex, it might not be any help, but there's really no way to know that without some experience in that area.

Of course, I keep throwing around the term big and small rather carelessly. Some attributes of an app that I think make it "big" would be:

- Gets enough use that fine-grained caching is import. It probably also needs to run across multiple servers.

- Does complex database queries where you _must_ do the restriction and joins on the dbms side in order to make things run at an acceptable level. Also, you must use iterators to fetch the data because the result sets can be very large.

- Besides complex queries, it also needs a sophisticated data manipulation interface for people to change things, for example something like a large store's catalog, too big to just browse. You need to be able to search, do bulk updates on search results, etc. The basic point is that lookup by id is not sufficient for most tasks.

There's probably other things that could be added, of course.

Re:My guesses ...

perrin on 2005-10-20T14:56:14

I think Maypole actually came well before Rails. Before Maypole, there was OpenInteract and Apache::PageKit, and of course all the others (like Mason) that aren't quite so squarely aimed at MVC apps.

It doesn't bother me that Rails is doing well. What does bother me is when these guys make it sound like they invented this stuff, and no one else has it. And, as you say, people who have never worked on large web apps seem totally willing to believe that Rails is the only thing that ever had had this stuff.

Incidentally, Class::DBI supports direct use of SQL. I wouldn't use it if it didn't. ActiveRecord doesn't seem to have anything that Class::DBI and it's optional extensions doesn't have. In fact it appears to lag behind in terms of using the database meta-data. It relies on naming conventions like mapping a class called "Country" to a table named "countries." (The DBAs I've worked with would have flayed me alive if I used plural names for my tables.)

Both of them look pretty weak compared to Java's Hibernate though, which supports a lot more table relationships, query capabilities, and caching options.

Re:My guesses ...

TeeJay on 2005-10-26T18:11:49

Before I start I should declare my vested interests - I use and maintain Maypole :)

Looking at the actual releases - Maypole 1.0 was released in Febuary 2004 and Rails wasn't released until April 2004, although development on what would become Rails was probably started 3 to 6 months before Maypole development was started.

I think Maypole is already more flexible in it's vanilla setup than Rails in it's vanilla setup.

The maypole developers need to keep an eye on Hibernate and Catalyst, as they are breaking new ground while Rails is deploying good applications.

There are several caching options available in Maypole, but I'm not actually planning to look at that until 2.12, we're focussing on ease of use before making it faster.

Also the relationships and querying in Maypole are currently closely tied to CDBI but in the next release (due early november) we have improved the model to handle more relationships more smoothly. Also in later versions other ORMs like Tangram and Oryx will provide more relationships and querying abilities.