reasons for not using Rails

couple of reasons for not using Rails are performance and scalability.  I’m actually confident in the development community and momentum behind Rails that these will soon be non-issues.  Enough so that I can’t use them as arguments against using Rails.  By the time performance & scalability would become an issue to One Shore or most other small shops, you could throw hardware at the solution, and besides, there are some promising developments that I think will probably make them irrelevant.

First, are the performance improvements.  A lot work is being done on that end, though by a lot of disparate groups.  Besides Ruby 1.9, there is Yarv, Rubinius, IronRuby, Ruby.NET, and JRuby.  With all this enthusiasm, whether it’s there yet or not, engineers will make Ruby performant.  Some collaboration might be in order, but it’s the healthy competition that will bring the results.

Sun is backing JRuby pretty hard, but most forcefully with the Netbeans Ruby IDE.  You can now fairly confidently scale Ruby via Java, with the attractive benefit of the JEE stack.  The other benefit is that if you are running on JRuby, you can push your complexity where it belongs, into Java.  (IronRuby promises similar integration benefits on the .NET stack.)  So you don’t have to worry about integration, web services, caching, etc.  On the other hand, JEE is very un-Rubaic(?) and people use Rails to avoid things like Hibernate and JSF.

Which brings be to my next argument –  Rails 2.1 — which has, among other things, nice built in memcached support.  Rails 2 is by most accounts a subtle, but significant improvement, with supposedly a relatively harmless migration.  Due to the relative lack of documentation (and plethora of existing documentation) however, I would
be hesitant to jump in with Rails 2.1.  Starting with 1.2.6 and an older book, and then trying to add features and clear warnings would be a good strategy.  6 months or a year from now, that probably won’t be as big of an issue however, except you’ll have to spend $100 for new books — that is if they get written.  There is a risk that the bulk of Rails’ userbase will migrate gradually and not feel a need to update their documentation.  If there is still an influx of new users, then the new docs will get written.

And finally, there is progress on the deployment end.  Everyone has read a rant or two about hosting Rails.  Mod_ruby was never more than a proof of concept, and even Zed Shaw pissed on Mongrel.   But, as predicted, big providers like Dreamhost leapt in to meet the demand, even if a bit slowly.  I’m excited with developments like Phusion Passenger which also markets a Ruby VM they call Ruby Enterprise Edition, probably hoping to be the Zend (not Zed) of Ruby.

If PHP had more competition like this, it might have had a credible story.

Don’t get me wrong, PHP is good at what it does, and still my “favored” language, but unless you’re dealing with stateless apps, it doesn’t have a prayer.  Even with stuff like Zend Framework, CakePHP, and Symfony, PHP doesn’t have the runtime for complexity.  Ruby didn’t either until recently.

But maybe it’s the passion people have for Ruby (and especially Rails) that makes the environment that PHP lacks coalesce.  PHP is popular because it can “get it done”, and when Perl and Java were the only alternatives (and with much better stacks), PHP was an easy winner.  With Ruby (and Python) now coming into their own, who knows?