rc3.org

Strong opinions, weakly held

What’s the ceiling for Rails?

Tim Bray predicts continued explosive growth for Ruby on Rails, and Joe Gregorio counters by saying that growth in Ruby on Rails has already plateaued (as he predicted), and has some graphs to back it up.

It’s inevitable that Ruby on Rails growth will plateau, Tim gets at perhaps the biggest reason why in his post predicting continued growth. He notes that developers on other platforms are paying attention to Ruby on Rails and figuring out how to apply some of the Rails goodness to their own frameworks. As people find Rails-esque features available in platforms they’re already familiar with, they’ll be less likely to learn Ruby and migrate to Rails.

Another factor that will limit the growth of Rails is that it really is best for new projects. Every time I think about rewriting an existing application in Rails or using Rails with a database that was not designed with Rails in mind, I blanch a little bit. It’s certainly possible to do so, but in the process you give up some of the Rails features that offer the biggest productivity gains. Even in the periods of the most fervent enthusiasm for Ruby on Rails, I didn’t see a big push to rewrite things in Rails.

The third factor that will limit the growth of Rails is that it’s difficult to get multiple Rails applications to play well together, or to get Rails to play well where multiple applications live on the same host. Many Web sites are an amalgamation of applications, perhaps running on different platforms. You may have some static content, a calendar application written in PHP, a blog powered by Movable Type or WordPress, and a PHP contact form. It’s easy to add another PHP application to the mix in its own directory, or even add a Java WAR file to the mix. Unfortunately, Rails really wants to control the virtual host it’s running on. Taking an existing Web site and putting a Rails app in /blog isn’t the easiest thing to do. It’s really a shame, because Ruby on Rails is the perfect framework for whipping up a job board, or a schedule of upcoming training events, or a customer support knowledge base.

If someone came to me today and said they’re trying to pick the technology platform for a new Web startup, I’d tell them to choose a modern framework built on a dynamic language. Django and Rails fit the bill, among others. But those types of projects are a small slice of the Web development work that’s being done these days. And it’s going to be tough for Rails to continue making inroads into the larger ecosystem, for reasons both technical and practical. The next big boost in Ruby on Rails growth will come when point #3 above is addressed and Rails deployment moves to the next level of simplicity.

4 Comments

  1. I always read your posts about Rails with a bit of envy. With the kind of software development work I do, the customer gets to decide what language we write in. And with that in mind, we are usually very lucky if we’re allowed to code something in Java instead of having to use COBOL on the mainframe. I mean, I have colleagues who envy me for having more than eight characters available for naming my files. With that in mind, though, the whole discussion about dynamic languages gaining speed always seems kind of ridiculous to me — compared to the huge amount of work going on in legacy languages, will the new languages ever matter? Certainly not in my world. I will just keep on dreaming of being able to use Java 5 some day…

  2. Regarding #3, Camping? http://code.whytheluckystiff.net/camping/wiki/SmallAppsManyMounts. Less feature-rich, but composable.

  3. For #3, I too am surprised that some fix for this has been slow to come along. I’ve had luck setting up Rails apps in Mongrel behind Apache’s mod_proxy_balancer (though admittedly I have no Rails apps that have scaling challenges).

    It seems it should be possible to create an Apache module (says the guy who’s never written one) that allows you–from httpd.conf or .htaccess to give shared users some control–to point a URL path at a physical path containing a Rails app and have it manage your Mongrels for you.

    Now if only I could justify spending my time on such a thing.

  4. FWIW, Perl’s entry in the MVC framework arena, Catalyst, is explicitly non-opinionated (and the dispatcher is brilliant, but that’s not the topic here), and the matching state-of-the-art ORM, DBIx::Class, is explicitly designed to deal with any schema you throw at it whatsoever. The pair is quite happy to serve as glue for putting legacy apps on the web.

Leave a Reply

Your email address will not be published.

*

© 2016 rc3.org

Theme by Anders NorenUp ↑