Ruby, Rails, and the mainstream

It seems I have stirred quite a pot around the office with my recent ravings about Rails. Today the tech-head on the board sent me this article about why Rails won’t make it into the mainstream and asked for my comments. The following is basically a translation of my reply to him (Gee, this is the closest I’ve ever come to being paid for blogging).

The right tool etc…

I believe Cedric is somewhat right in concluding that Ruby and Rails will never make it to the mainstream - in particular when you define the mainstream as the regular, average programmer. PHP sits nicely in its niche of being a widely adopted, easily accessible language where you can achieve results with a minimum of fuss.

I am not certain that the battle against PHP for the mainstream market of regular programmers is a battle Rails should or even wants to pick. As Cedric points out, most concepts and ideas behind Ruby and Rails go above the head of the average website and the resident programmer, and in most cases they don’t even matter. A project needs a certain complexity before writing it in Rails manifests itself as a benefit. It is no coincidence that the “static” pages on rubyonrails.org are written in PHP (well, more like written in HTML and glued together with a bit of PHP to avoid repeating stuff). PHP is an obvious and excellent solution when the problem is simple.

Even creating the simplest of hello world applications in Rails is a 23MB RAM consuming, 5 step process - and that doesn’t even cover the deployment to a webserver. In PHP it’s a simple matter of uploading a file containing <?= “Hello world” ?> to your webserver, and you’re set. Rails won’t ever win that battle.

Rather, I see Rails targetting the crowd of developers who build web applications and realize the benefits of design patterns, automated testing, object oriented programming, and consistent, well-structured code. Ruby and Rails try to bring the ease-of-use of PHP to Java while bringing the structure of Java to PHP. The result is a beautiful package; a language and framework with great power and flexibility and with enforced structure where it makes sense.

Chickens and eggs

Returning to Cedrics article, it seems ripe with “The chicken and the egg” situations. Half the points he raise are self-fulfilling prophecies that will stay true until someone choose to act against the prophecy. Which is only natural, since that’s partly the big issue Ruby and Rails face at the moment:

“The Enterprise” hasn’t yet adopted Ruby and Rails, because “The Enterprise” hasn’t adopted Rails yet. Rails isn’t widely available at hosting companies, because it’s not mainstream, and Rails isn’t mainstream because it’s not widely available at hosting companies. Luckily some hosting companies and bigger companies are at least open to Rails adoption.

Think about the humans

It’s interesting to note, that Cedrics “conviction doesn’t come from technical grounds”. His arguments are based in human values and emotions like security (in the “I feel safe” sense, not the “I’ll take stuff Windows is lacking for 500, Alec” sense), fear of change, and why fix it if it’s not broken.

It is indeed important to look away from the purely technical side when evaluating Rails. Rails is built on the premise that code and development must be beautiful and non-tedious, since that’s what make developers happy. If Ruby and Rails doesn’t make it into the mainstream it will not be due to lacking technical merits. It will be due to human emotions.

Comments

softrockcookie April 7, 2006

I am with you at all points of the argumentation.
The main point for me is also that Rails and PHP have completely different target groups. However, as Rails is still in its very beginnings, maybe it will develop in an unexpected way... who knows? I'd like also to know what you think auf Groovy and Grails
Is this necessary or more a gag?

Tomas Jogin April 7, 2006

If Rails never becomes more popular than it is right now, I won't care one way or the other, because I don't need Rails to be mainstream to be able to use it happily and effectively.

Art of Mission April 8, 2006

Cedric has an interesting article about Why Ruby on Rails Won

Read the rest on Art of Mission

Komodo Coder April 9, 2006

Not to get off-topic too much, but I've latched on to your statement about the "Hello World!" program taking 30 MB of RAM to run? I'm using Rails 1.1 and I saw that running WEBrick takes 23 MB, but "Hello World!" seems to consume nothing extra. Just for my learning and edification, can you explain what you meant? Thanks - love the blog!

Jakob S April 9, 2006

Komodo, I grabbed that figure from the back of my head, seeming to remember that's how much my dispatchers on Guildspace uses. I'll change it to 23MB to be more in line with the actual figure.

Angus McDonald April 12, 2006

Jakob,

I think Komodo's point is that WEBrick is the built-in web server that you are recommended against using in a production environment - i.e. it should be compared to the Apache web server's hit on RAM when using PHP. Except that Rails can use the same web servers that PHP can, so the difference is probably a LOT smaller.

Jakob S April 12, 2006

Do a ps axww | grep php on most systems running PHP on Apache and you'll get no results. Do ps axww | grep ruby on a Rails server and you'll have your dispatchers listed, each of them taking up around 20-30MB RAM.

I don't know what the actual difference is, but the perceived difference is right there.

Commenting on this entry has been closed.