Blog archives don’t lie. It’s been nearly 4 years since I first “blogged about Ruby on Rails”:manton.org/2005/02/t… (Three years and 10 months, but I’m not patient enough to wait until February to post this.) Here’s a portion of what I said back then:
"But the PHP people will switch, easily, and with the apparent momentum of Ruby right now, maybe it's already happening. Forget the enterprise for now. Rails is a perfect fit for anyone who develops for the web on its own terms, and the people behind apps like Basecamp, 43things, and the upcoming Odeo match that profile."
In that time I’ve increase my use of Rails. At “VitalSource”:www.vitalsource.com we have a bunch of Xserves running Rails applications. Mac developers have embraced Rails in the form of “PotionStore”:www.potionfactory.com/potionsto… Cheap shared hosts have been replaced with virtual servers, “many”:www.railsmachine.com with an emphasis on Rails hosting.
The community is huge now. What’s not to like?
Plenty! Here are my top gripes about Ruby on Rails.
Deployment. Ask anyone — even its biggest fans — and they will complain about deploying Rails applications. This stems from two points: the overhead to initializing a Rails application, meaning multiple instances have to be fired up and ready, unlike PHP which can process a script at a moment’s notice; and the path of ever-changing deployment strategies littered with the corpses of FCGI, Mongrel, Passenger, Thin, and more.
Upgrades. Rails matured quickly and is constantly improving. That’s great for features, great for best practices, and great for a clean API. The downside is that methods and entire chunks of the framework are deprecated and removed every major release. Forget about backwards compatibility. If you aren’t reading the blogs and keeping up with the latest changes, you’ll pay a price when it comes time to upgrade your application.
Attitude. David Heinemeier Hansson and the Rails core team have been outspoken in their lack of concern for end users. It’s because Rails is not actually a product. It was released and is open source to benefit the community and to grow the framework, but average developers should have no misconception that anyone with Git commit access is looking out for their application. I have great respect for Hansson, as well as the other high-profile developers of Rails, but it helps set expectations to underscore that Rails is not a supported product.
Java. Developers new to Rails generally come from the two other most popular web development languages: PHP and Java. Many leaders in the community come from that latter group, some of whom I count among my friends. Chad Fowler, in his “interview with Pragmatic”:www.pragprog.com/podcasts/… spoke to the baggage that developers bring to a new platform. I think some of this baggage from a more “serious” architecture is leading to new complex abstractions, such as Capistrano. Whether fair or not, I also largely blame the Java developers for using tabs-as-spaces, which is evil. ;-)
Extensibility. The Rails team wisely made a conscious effort to limit the number of features in the core of Rails, instead preferring new optional features to be implemented as gems or plug-ins. The problem is that there are limited hooks to extend the framework. Ruby is great at dynamically extending classes that weren’t designed with extensibility in mind, but there is no gaurantee that one plug-in’s monkey-patch will continue to work in future versions. Ironically, “merging Merb”:weblog.rubyonrails.org/2008/12/2… into Rails 3 will bring better supported APIs for plug-in authors while no doubt breaking a bunch of old stuff.
Speed. I put this one last because I don’t actually think it’s as big of a show-stopper as many people think. Still, it’s true that Ruby is one of the slowest languages out there, falling behind Python, Perl, PHP, Java, and enormously behind compiled languages. ActiveRecord is great, but it also makes developers lazy and requires tweaking the defaults to achieve the same performance as hand-rolled SQL. Projects like “Rails Metal”:weblog.rubyonrails.org/2008/12/2… look very cool, though, so that’s a good sign for the platform.
Even with all these critiques, there is something special about Rails and I will continue to use it for many applications. But at the same time, any shame I used to have at using PHP is gone. If I need to do something simple, I will use a simple solution. As a sort of backlash against my frustrations with Rails, I built everything that powers Riverfold (order processing, admin interfaces, the “Wii Codes application”:wiitransfer.com/codes/ and Twitter services) off of PHP.
