Update: here is a follow-up to this article, written two years later.

You won’t be reading any Ruby on Rails bashing in this blog post for a simple reason:  I love Ruby and I love Ruby on Rails.

Rails is a fantastic framework built on a wonderful language that appealed to me the very first day I started to study it.  I think David did a fantastic job in two areas:

  • Coming up with innovative ideas that take Web programming to a new level.
  • Leveraging the strength of Ruby to achieve his goal.

To tell the truth, the Pick Axe and Agile Web Development with Rails books are the best two technical books I have read these past years.  I read quite a few technical books, but none has caught my interest and made me look forward to resuming my reading more than these two books.  And to top it all, features such as Headless Applications, as illustrated in this blog post by Mike Clark, clearly show how powerful Rails is.

There is no denying that Ruby on Rails is turning the Web programming world on its head.

Now that this introduction is out of the way, I’d like to take some time to explain why, in spite of all its qualities, Ruby on Rails will never become mainstream.

As you probably guessed, my conviction doesn’t come from technical grounds. 

The truth is that there are a lot of forces involved in making a Web framework successful, but before I dive into those, allow me to tell a little side story.

Have you ever come across Smalltalk or Lisp programmers?  You know, these people who, no matter what you tell them, will always respond that "Smalltalk did that twenty years ago" or that "Nothing has been invented since Lisp".  They listen to you patiently with an amused light in their eyes and when you’re done talking, they will just shrug away your points and kindly recommend that you read up on a thirty-year old technology that was the last thing they ever learned and that has been dictating every single technical judgment they have offered since then.

I believe that in ten years from now, people will look back at Ruby on Rails and will have the same reaction.  I’m not sure what Web frameworks we will have by then, but I’m quite convinced that a lot of the current Ruby on Rails fanatics will have the same kind of attitude:  "That’s nice, but Ruby on Rails already did this ten years ago, and better".

Interestingly, they might even be right.  But by then, it won’t matter because despite its technical excellence, Ruby on Rails will still be a niche technology that only experts know about.

So why do I think that Ruby on Rails will never cross the chasm?

  • First of all, Ruby.

    Again, and at the risk of repeating myself:  I love Ruby.  I truly do.  It’s one of the few languages that I have studied these past years that made me go "Yeah!" whenever I read about a feature I didn’t know of yet.  I find its syntax and concepts extremely elegant and powerful at the same time.  I don’t like everything about it, of course, but Ruby is by far the number two language in my toolbox behind Java, with number three far, far behind.  But it’s a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb.

    Admittedly, PHP and Visual Basic are cheap targets (we’re talking about languages that don’t even have name spaces!), but like it or not, they are the Web standard.  Anyone who wants to succeed in the Web arena must have a compelling story to tell to these programmers, something that will convince them to switch to Rails on technical grounds but that will also be an easy sell to their management.  Rails can’t succeed without these two conditions, and I am predicting that Ruby — and Ruby on Rails — will always remain a tough sell to any organization that contains more than ten people.
     

  • Ruby on Rails itself.

    Ruby on Rails is just too advanced.  I’m serious.  It has an incredible amount of slick features involving a lot of magic (both Ruby-related and invented by David himself).  For talented developers, these features are a dream come true…  autowiring of the MVC, scaffolding, defaults over configuration, unit tests (even integration tests now, nice!), you name it.  David hit every single pain point that Web developers (regular developers even) have been facing these past years.  Ruby on Rails in itself is a great example of how to nicely package what we have learned about software development these past five years.

    But it’s still a very wide gap for corporate developers to cross.  Sometimes, too much magic is too much magic, and it can definitely be the case that the flow of code is too direct or too clever to be understandable by regular developers.  Developers were able to do the jump from imperative to object-oriented programming, but it was a hard fight.  I don’t believe the Web world will ever be ready to embrace the Rails cleverness.
     

  • Still no credible IDE.

    All fanatics of dynamic languages are quick to point that they don’t need an IDE to use Ruby, Python, Groovy or other.  And they will quickly add that if you need one, you’re probably not being rubyic or pythonic enough and that you should probably switch back to your old language and leave the grown ups alone.

    This is nonsense.  Ignore these people, they don’t understand how the real world works and how developers think, and they are one of the reasons why so many great technologies never make it to the mainstream.  Don’t ever be ashamed to need an IDE or to ask for one.  Of course, there are bad ways to use an IDE (e.g. you want code generated for you) but if you are interested in Ruby on Rails, chances are that you are a decent developer and you know how to leverage an IDE to make you more productive than when using emacs.  Code completion or navigation, debugging, refactoring, project management, source control integration, etc…  there are too many features to list that make you more productive if you use a tool that enables them.
    This is 2006, not 1996.  The programs we are writing and the problems we are solving every day are orders of magnitude harder than back then, and our tools need to keep up with that need.  Emacs is a fine text editor, but it’s no longer adequate for modern development.
     

  • Fanaticism.

    Regular readers of my blog know how strongly I feel on this topic.  There are exceptions, of course, but the attitude of Ruby on Rails users toward Ruby skeptics or critics has been less than kind.  This is a crowd convinced that it has found the ultimate answer to everything, and they are not afraid to let you know.  I only have a simple advice for these people:  you might be right, but just be humble.  It never hurts.
     

  • Crowd of a single mind.

    If you want to write a Web application in Ruby, there is only one solution.  Only one.  Ruby on Rails.

    Ruby on Rails has pretty much nuked the field of Web development in Ruby, and I wonder if it’s such a good thing.  For all the flak that Java receives because you can count at least a dozen different Web frameworks, there is something to be said about plurality and the constant chase for something better and different.  Each framework that comes out builds on the strengths of its ancestors while discarding the errors (and committing a few mistakes of its own, of course). The field advances a little bit every time while bowing down to the timeless laws of natural selection.

    I am worried that Ruby on Rails will do to the Ruby world what JUnit did to Java:  a great tool when it came out but which condemned its community to an ice age where no innovation or competition appeared for years.  Whatever the fate of Ruby, I hope its fans will keep an open mind and will constantly challenge the Rails way, for the simple reason that it’s always healthy to question what’s in place, no matter how good it looks.
     

  • Enterprise capabilities and scalability unclear.

    This is an argument that the Rails crowd doesn’t take well, and they are quick to point out BaseCamp and other products.  The problem is that by now, there should be other obvious success Rails stories, and not just ones developed by the Rails Society.  Of course, it’s a chicken and egg problem:  a lot of companies evaluate Ruby on Rails but will only take the jump if they can find evidence that other companies have done that before them.  And for now, the evidence is scarce at best.

    Granted, Java took a while to rise to the enterprise challenge as well, and it did so despite tremendous initial handicaps such as poor performances and questionable specifications.  I contend that until Rails goes through its own EJB2 debacle, it won’t be seen as enterprise ready.
     

  • Lack of support from Internet Providers.

    What’s the big deal with this, you ask?  After all, Java is hardly supported by Internet Providers as well.  The big difference is that Java on the server is targeted at the enterprise.  Anyone who wants to run a Java EE application will most likely host their own servers.

    Ruby on Rails is targeting a different population:  the "Web sites in-between", these sites that are not massively scalable but still have more than a few visits per day.  A lot of these people use external hosting, and they won’t go very far if Rails is not offered natively and pre-installed for them.  PHP is a no-brainer for them, because it’s installed virtually on 99% of Internet Providers.

    Of course, a little bit of .htaccess magic will allow you to run your own Rails application, whether your provider supports it or not, and assuming that they give you that amount of privileges and that you don’t need to scale too high, but until Ruby on Rails achieves at least half of the PHP penetration, it will remain inaccessible to most of the population it needs to become mainstream.

Note that I didn’t say anything about poor error reporting, weak internationalization support or Active Record, which are usually the areas where Ruby on Rails is the most criticized.  I’m not worried about these because they are simply a symptom of Ruby on Rails’ youth.  They will be fixed in time, and I don’t think they will play a big role in Ruby in Rails’ acceptance (or lack thereof).

So there you have it.  My prediction on Ruby on Rails in one, lengthy post.  I apologize for the size of this article, I usually try to keep my blog entries short and to the point.  I hope at least that I achieved the latter.

I’ll conclude on a positive note:  I hope I’m wrong.  I really, sincerely do.  For my next work, I want to have a choice between Java and Ruby, but right now, when in doubt, even I usually end up returning to Java for my personal projects for the reasons listed above.

And as you know, I love it when frameworks and languages compete for my business.  But right now, I see no competition.