Should I heed Derek Sivers' warnings about migrating from PHP to Rails?

Question

As you probably know, Derek Sivers is the guy who created CD Baby and eventually sold it for some big bucks. He wrote it in PHP originally and then down the road set about rewriting it in Rails. His troubles are the stuff of legend:

7 reasons I switched back to PHP after 2 years on Rails

That article came out in 2007 but being newly infatuated with Rails, I'm wondering whether anything has changed to make Rails more of a wise bet in the meantime, or should I stick with my good old ugly PHP girlfriend?

Does anyone agree that Rails does not offer any significant advantages over PHP?

Answer 1

Austin Ziegler wrote an interesting response to that article:

On Derek Siver’s Return to PHP…

The gist of it is:

1. Derek chose the technology for the wrong reasons. He chose it partially based on the hype of Rails, but he envisioned it as a silver bullet that would magically make his application better just because it’s in Rails.

2. Rails didn’t fit Derek’s application model for CD Baby, and Derek’s application model is more important than the technology to be used, since it represents a business he understands well.

3. He ignored his existing experts for the new technology. Neither he nor his employees knew Ruby aside, perhaps, from playing around with it. This wasn’t a technology that was deemed to be appropriate from experience; this was a technology deemed appropriate by management (sorry Derek, you might still be getting your hands dirty with code, but you’re still management).

4. Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment, without considering ways to phase it in over time. It’s almost always possible to find interface points where you can replace one broken piece at a time. Ultimately, this is what the Rails folks wouldshould tell you anyway: replace one area at a time, each with a different codebase. Interface them as REST-ful services. Don’t make them depend on a single database schema.

Answer 2

Luke Crawford's recent post about Muxtape offers another perspective.

I spent my first 4 years as a web developer using PHP, and it was fun at the time, but as I began to realize how severely inefficient it was I started looking elsewhere. I’d abandoned my traditional computer science background for the web and its greater design possibilities, but because of this I knew there was a better way. PHP developers shouldn’t be ridiculed as much as they often are because, frankly, it enables people without a more rigorous background to accomplish amazingly technical things. This should satisfy nerds but usually is turned into some kind of weak ‘machismo’ thing instead. Anyways, this dissatisfaction began in late 2004 and Ruby on Rails was brand-new, stable, and addressed every limitation I’d confronted with my old homegrown PHP MVC framework. I’ve exclusively done Rails work ever since.

In any case, it would be hard to defend the categorical statement "Rails does not offer any significant advantages over PHP."

PHP is a great tool to solve certain problems. Rails is a great tool to solve certain problems.

Answer 3

I have experience with PHP & Ruby + Ruby on Rails (earned money using both, but not a lot).

The Ruby library is much better. PHP's library is a collection of functions in a global namespace with inconsistent names and argument order. strpos vs str_repeat. strpos's first argument is the big string and the second argument is the string to find. explode's first argument is the string to split by and the second argument is the big string. This was a big problem for me. I had to look up a lot of things when using PHP, but not when using Ruby. I can remember things because they're consistent. The names of the methods make argument order clear. Another: PHP's strlen($str) vs count($arr) while in Ruby it's just anything.length.

Ruby the language is better than PHP. It has closures, good OO, nice syntax (this is subjective, but you need a lot less punctuation in Ruby, and that's what I get wrong most often).

That's my experience. Try both and see what works for you.

Answer 4

Re-writes of existing sites are almost always a bad idea. It's hard to put your heart into retreading an old wheel. I worked on a rewrite of a site from CGIs to a Java app server and saw several programmers quit because of it. For one, they preferred their old way of ding things and did not want to learn Java. Secondly, I believe they did not have the enthusiasm to re-write a ton of legacy code that they had been maintaining reluctantly to begin with. Far better to try Rails out on a new task and see how it fares. At least then you are putting it on an even footing with PHP in the psychological motivation sweepstakes.

Answer 5

As both an active Rails and PHP developer (with experience going back to 2000), I strongly disagree with the statement.

I maintain that Ruby offers significant advantages over PHP, and Rails is a better framework than anything in the PHP world. A lot of this has to do with the language itself - Ruby can do things that PHP just simply cannot. Once you grok the elegance of meta-programming, a whole new level of expressiveness opens up to you.

Answer 6

Rails is a good framework, but sometimes migrations are bad ideas. I prefer to start from scratch, you can't be "translating" PHP code into the Rails context. It just can't be done, mostly because of the Ruby language itself and the MVC pattern.

Answer 7

I'd rewrite it in Rails, but if you love PHP, go with PHP. Don't care about what other people say, do whatever suits you.

Answer 8

In business, time is money - and sometimes you have to go the path of least resistance. No environment, language, framework, etc. is perfect. Learn and use what you want to and keep it movin' homeboys!!!!

Answer 9

I read that post from Derek Silvers. There is something weird about it. He tells the tale of a project that got out of control, dragged on for months, and eventually had to be abandoned. He blames this on the Rails framework. Yet he never says what it was about Rails that caused the project to fail. The article would be far more credible if he offered some solid information, but he doesn't mention even one specific place where Rails let him down. The closest he comes is to say that their "needs" (?) clashed with Rails's preferences (which ones? How?)

Meanwhile, people all over the world (including myself) are implementing complex Web applications in reasonable amounts of time using Ruby on Rails.

Given the lack of detail, or really any specific technical information at all, in Derek's piece, it could easily be that the project failed for any number of reasons having nothing to do with Rails.

The original question was "should I heed Derek Silvers' warnings about migrating from PHP to Rails?" My answer would be no, his "warnings" amount to a vague anecdote with zero supporting evidence. It is perfectly safe to ignore them.

Should you reimplement a PHP app in Rails? That's another question. There is no blanket answer to that one. It depends entirely on circumstances.

Answer 10

The best answer will be the author's himself. He seems to make another comeback to RoR!:

Foreword

My former company (CD Baby) was one of the first to loudly switch to Ruby on Rails, and then even more loudly switch back to PHP (Google me to read about the drama). This book by Michael Hartl came so highly recommended that I had to try it, and Ruby on Rails Tutorial is what I used to switch back to Rails again.

http://railstutorial.org/book

And skimming his own site, indeed, proves his return to RoR:

Rails 3

Instead of trying to teach everyone my unique PHP framework, all

projects will standardize on Rails 3.

http://thoughts.pro/

The guys who changed from Rails to PHP just by following the renowned article of his, now it is your time to come back to Rails, again!