And so the critical backlash against Ruby on Rails has truly gotten underway. Elliotte Rusty Harold: “a very common mistake made by developers who are mired in 1980s style of applications and have never understood the Web, and probably never will.” Steven Noels: “the advent of using a platform which requires you to worry about shooting blanks isn’t very appealing to me.” Berin Loritsch: “integration with Apache2 is shaky at best and I get unexplained errors between development and production environments.”
I’m sure this is just the beginning, as more and more people make the switch to Rails, only to find that what they gain in quick initial results they lose due to the framework’s immaturity. Which brings me to what I’ve been thinking almost ever since David first introduced me to Rails last year: the true value of Rails is not necessarily the framework itself.
The true value is in what Rails has taught us about who we are and how we do our jobs. Write less code. Convention over configuration. Don’t repeat yourself. These are all common-sense statements, and the lesson is that someone needed to remind us of them, and challenge our assumptions about how we approach the problem of web applications.
For those of us that have been in this game for a while, and have progressed steadily from CGIs written in C to scripts written in Perl, to PHP and ASP then JSP and J2EE, it feels like we’ve made steady progress and improved on what went before. But starting with a fresh canvas, as the Rails community have done, teaches us a lot about the baggage we’ve carried with us in our quest to improve on the frameworks we used before. XML sit-ups seemed like a small price to pay for dispensing with the legacy of CGIs and scripting languages. But Rails shows us that we should be braver, and define our best practices, so we can let the computer do more work for us.