Derek Sivers of cdbaby.com has posted an interesting editorial piece on the O’Reilly Ruby site regarding his switch from Ruby on Rails back to PHP. It’s caused quite a storm of discussion on slashdot. While some people think it really shows some flaws in the RoR platform, and others think that he is totally off base, I think the main point is something both of those groups have missed. The method is often more important than the technology.

As Derek points out, RoR wasn’t the cure-all framework of rapid site development that it’s often advertised at. Even with one of the world’s leading Rails developers, he wasn’t able to build their site up to spec in an extremely long period of time. The problem was, Rails is a framework that’s set in its ways. You have to conform to the certain methods it uses to achieve some goals. If you don’t like it? Tough. While it provides many convenience features that make developing sites faster and easier, once you hit a point where the way you want to do something differs from the way you have to do it in rails, you’re stuck. It’s not going to happen without a lot of hacks.

Later in the article, Derek concludes he was able to achieve many of the benefits of the Rails framework by creating some of his own Rails-like constructs in PHP and building his whole framework to suit his needs. It’s a win-win scenario. So what does this say about Rails, PHP, software development, and everything?

Essentially, the strength of Rails, and pretty much any other framework, is the way that it approaches some problems and provides abstractions that simplify the solution. However, this convenience doesn’t come without its drawbacks: the extra baggage that doesn’t suit your needs. What’s more important is to know these useful techniques and abstractions and be able to apply them in your own solutions. This way you can get away without dragging a whole heavyweight framework in to the mix.

Update: There’s some commentary on some of the ravenous Rails fanatics over at the Pervasive Code blog.