I normally don’t jump into the PHP vs Ruby/Rails debates but this time I can’t help myself. Found via Darcy Whyte, Derek Sivers’ provocatively titled article 7 reasons I switched back to PHP after 2 years on Rails deserves a reply from the Rails community.
Let’s start with his quote: “…twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences.”
Derek switched his project from PHP to Rails, didn’t do things “The Rails Way” and wonders why it was difficult. The project failed and he rewrote the new version in PHP in two months, creating a smaller and custom framework inspired by Rails in the process.
The Rails framework helps developers if they follow the conventions and can hurt them if they deviate too far from them. Jeremy Kemper (bitsweat) knows this — as do all good Ruby on Rails developers. From his description of his project, it sounds like Derek used Rails improperly.
Maybe Jeremy should have been more assertive about how Rails is meant to do things and explained The Rails Way better. When you’re a Rails expert that’s part of your job because people are still getting used to Rails’ new approach and how it can help them. A Rails expert needs to explain to his boss the impact and risk of deviating too far from The Rails Way.
Of course PHP is a better solution than Rails for writing a custom framework, it’s a programming language. He would have been just as successful writing his custom framework in Ruby. Trying to “twist” a framework like Rails into a custom framework is just asking for trouble. Use a hammer for nails, don’t blame a wrench for not working well.
Sure, Rails has “The Rails Way” conventions for developers but that doesn’t mean it’s too templated and all Rails applications end up looking the same to users. There’s a lot of UI flexibility available and copying existing “web 2.0” look and feel is a design decision. From the outside Rails applications can look like applications from any other framework or programming language.
Quote: “Is there anything Rails/Ruby can do that PHP can’t do?”
No, there probably isn’t. Is there anything PHP can do that Ruby/Rails can’t? From the end-user perspective, probably not. So we’re in a dead heat — but that argument is a red herring.
If you follow The Rails Way, development can be *faster* than PHP because a lot of things are done for you, like object persistence with ActiveRecord. The tools need to be used as they were intended.
The moral for Rails projects is this: Learn about The Rails Way before you start. Don’t go off the rails and override a lot of the default behaviour if you can’t handle the business risk of doing so. Pun intended.