Tim Martin's blog

“[Rails] gained a lot of its focus and appeal because I didn’t try to please people who didn’t share
my problems.” — David Heinemeier Hansson

I always used to maintain that Ruby on Rails was a blight on the world of software development that wasn’t just making individual sites worse, it was making developers worse. Yet here I am a few years on, having chosen to develop my new web application in Ruby on Rails. What gives?

Some of my criticisms still hold up. Rails still encourages beginners to think of every single data-storage requirement as a nail waiting for the hammer of active record. It’s still too easy to write code that doesn’t scale. Above all, while the tutorials are blissfully easy it can still be a hard slog learning what’s going on under the hood, so that you can do more than just cut and paste tutorial code. I believe Rails has improved on each one of these points, but not yet enough for my liking.

Yet I was wrong about Rails, and part of the reason I was wrong goes back to a truth I’ve always held to be under-appreciated: when you choose a technology, you inevitably choose a community at the same time. The Rails community may border on the smug from time to time, but it also seems to have an above-average number of developers who are smart and get things done. Developers who aren’t just happy to do things the same old flawed way, but want to find a better way, and make it work for people. Above all, they deliver solutions that work now, not promising-but-currently-flawed solutions. This was typified by my serendipitous discovery of Timecop, a library that makes testing of time-sensitive code about as easy and effective as it could possibly be. Any language could solve that problem, but in Rails I have a solution right now, with no fuss (yes, I’m sure this particular example is solved in lots of other web frameworks too).

None of this is about the language per se. Rails isn’t better than Zend Framework because Ruby is better than PHP (it is, but the differences come up surprisingly rarely). Rails is better than Zend Framework because Rails has a complete suite of solutions for DB schema management, functional testing, unit testing etc., while Zend Framework plays catch-up. As far as I’ve seen, PHP has nothing to touch Heroku for ease of deployment.

Web development certainly has different challenges from all other development environments. I used to worry that statelessness was a major problem, and I felt that continuation-based frameworks like Seaside and UnCommon Web held the most promise for resolving this. I was wrong, to the extent that while state is consistently a problem there’s a “good enough” solution in the form of MVC, while streamlined automated functional testing of web apps (which Rails does admirably with a test suite based on CSS selectors) brings massive benefit right here and now, rather than in a utopian future.

\" gained a lot of its focus and appeal because I didn’t try to please people who didn’t share my problems.\" — David Heinemeier Hansson I always used to maintain that Ruby on Rails was a blight on the world of software development that wasn\'t just making individual sites worse, it was making developers worse. Yet ...