2005/07/26

The Rails debate

The argument between the Rails camp and the Java camp is actually quite interesting, as the first phase of FUD (from either side) is past. And there's an agreement that is slowly emerging which is basically: "It's the workflow, stupid".

Starting with a fully configured application base, bootstrapping the app with scaffolding, have really iterative development with a dynamic language and no class-reload issues. For all these aspects, the J2EE tools are clearly in the dust, and this is why Rails is the clear winner in the small project / new projects areas. I'm not talking other kinds as I think we don't have enough feedback from large or very large Rails applications, and of course with maintenance of Rails app.

On the other hand, what is missing on the Rails side is the tools, the platform and the deployment. I want the tools: I want a great Ruby IDE, with a Rails personality. I'd love a much larger set of Ruby libraries: not necessarly core libraries, but a huge ecosystem of external tools and classes, like what we have in Java (and, on a lesser scale, on Python). And what I'd really love right now is something to facilitate deployment of my rails app. I want to have my webbrick tested app and push a single button or run a single script to have it deployed on my production server on apache or lighthttpd. I'd love to see something likethis, as easy to setup as the database.yml.

Even if a big part of Rails success comes from very smart 'marketing', it's really unusual and refreshing to have this attention to details (development process, initial phases of the application life, etc) in an open-source project. It's also interesting that the debate is mainly raging between the rails and java camp, and not much with PHP and Python developers.


Comments:
Another missing thing in RoR (but don't get me wrong, this is also something that is missed in the j2ee world, afaik), and which is also part of an article by JD Davidson, is a database agnostic schema creation tool.
Currently, most people will write a sql file which may (or not) include more or less subtle database vendor specific instructions (like, the dbtype, the sequences, the backquotes...) which won't work with another database which could be used by active record anyway.
There are things that are appearing (like, the migration task in the default rakefile), but this is still a big point.

Another question would be clustering. In the J2EE world, with most servers, you can share sessions between appservers and have a single webserver in front that will dispatch its requests within a group. What is the RoR answer ? Multiple lighttpd + multiple RoR instances over fast_cgi? Time will tell...
 
I completely agree with the need for a database agnostic schema creation tool. Even if there is still a lot of way to write custom SQL when coding a Rails app, ActiveRecord is already playing the role of the database agnostic layer, so that would completely make sense to complement this with a creation tool. Actually this is where the Great Elder WebObjects really shines, with the EOModeler tool: you could design your data model, or reverse-engineer your existing database schema, and have a base for your WO application. Something which now also exists client-side, with CoreData and XCode modeler.
 
Furrfu! Again, another Tiger/XCode2 feature!
Salesman! :)
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?