

7 reasons I switched back to PHP after 2 years on Rails - O'Reilly Ruby - luccastera
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

======
ericb
When I have seen large rewrites fail, it's often because of an all-or-nothing
rather than iterative or staged approach. At my previous company, 2 different
managers approached the migration of a massive VB6 project. The first tried a
total rewrite in C#. The code was ingenious and better in many ways, but
ultimately it failed after many wasted man-years, and he was let-go. There was
just too much hidden wisdom in the spaghetti code to replace it quickly and
easily. A wiser manager, and friend of mine, managed the rewrite, but in
stages. He would carve out a chunk, and have it replaced. He's a director
there now.

------
DocSavage
Summary: (1) He's a better programmer now, having internalized RoR best
practices, and can apply it to raw PHP code, (2) Decreased load issues, (3)
All company code can be PHP, and it sounds like there was a lot of legacy code
that didn't play well with Rails portion.

Would have been nice to read more about the mismatch points between Rails and
legacy code. Was this a legacy DB structure that couldn't be loosely coupled
to the Rails side, e.g., exposed as an internal REST service?

I also wonder if others can just as easily extend his code than if he had used
a well-documented framework like Rails. In any case, it's impressive he
rewrote the whole system (doesn't look like a small web app) in 2 months.

~~~
hello_moto
Correct me if I'm wrong. But I keep hearing (from the community) that the word
"well-documented" rarely showed up next to "Rails"

~~~
sbraford
In the rails API docs (api.rubyonrails.org) next to each function you can
click 'show source' to see what's going on under the hood. I hardly have to do
this.

But when I do, it's usually just 5-20 lines of code that's not that complex to
grok. (but you're right, not many comments inline) It would not be fun to try
and decipher RoR internals as a new ruby programmer.

~~~
DocSavage
There's also the caboose edge API documentation. It's updated 3x per day from
the most recent rails edge code and has all the private (#:nodoc) methods
exposed:

<http://caboo.se/doc.html>

If you think rails internals needs more documentation and can help, check out
the Rails Documentation project:

<http://www.railsdocumentation.org/>

------
blader
The title's kind of misleading. It's not like the guy gave up on Rails, he
even said that for future projects he would love to use Rails if it was
designed for Rails for the ground up.

It sounds like he was trying to using Rails to retrofit on to an existing PHP
DB schema, which is an obvious nightmare and probably a stupid idea in the
first place.

~~~
tyler
Its really not as bad as you might guess. It takes some time up front to go
through each model and tell it what the actual table name is, what the actual
primary key is, and etc.

Once that is complete though, its pretty much Rails business as usual.

This might not be practical for all applications. But, in looking at CDBaby, I
would find it hard to believe that their data is all that complex.

------
whacked_new
... because of a 404? J/K

The correct link is here, please update it and delete me.
[http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...](http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html)

And it's odd that this post has 2 points while being a 404.

~~~
jsjenkins168
Strangely, it went 404 right after I read it the first time. The link must
have been changed very shortly after this was posted.

------
breck
I think this article gets to the heart of the matter. Coding in Rails is much
nicer. But PHP is still a very easy and capable language, and will continue to
be the BEST language for large-scale Web Apps for many years to come IMHO.

Coding in another language like Ruby helps improve programming skills
tremendously. But then it makes sense to apply those improved skills and
learned design patterns to code PHP apps.

~~~
Zak
Neither you nor Derek Sivers has made a case for PHP being the best language
for large-scale web apps. In fact, Sivers only makes one argument for PHP:
it's "small and fast". The rest of his arguments are either against Rails or
against switching platforms for part of a production system that still needs
to integrate with the old platform.

Unsupported blanket statements don't contribute anything useful to the
discussion.

~~~
breck
Sorry you're right I didn't make any kind of a case. In making claims I prefer
statistics to theoretical proofs. I would rather take a quick look at the
statistics of large-scale web apps than make any kind of formalized argument
about which is better: PHP or Ruby.

I don't have any numbers off hand(I will find some when I have some free time)
but I would _assume_ PHP has 10x more large scale websites than Rails.

That's case closed for me. Although Rails is nice and fun. But if I have to
make a business decision today, its PHP all the way.

~~~
Zak
So your argument can be summarized as "I guess PHP is the best option"? That
still sounds like an unsupported opinion.

Let's assume you're right, and that there are ten times as many "large scale"
(whatever that means) websites running on PHP as Rails. That might mean that
an equal number of people have tried building large scale websites using PHP
and Rails, and that ten times as many failed using Rails as PHP. Do you think
that's the case?

5 minutes of searching on Google fails to return any conclusive numbers, but
PHP certainly seems to be several times more popular than Rails. PHP has also
been around for 13 years, while Rails was first released to the public just
three years ago. Both have been gaining popularity since their introduction,
which suggests an explanation for the greater number of large scale PHP sites
having nothing to do with the suitability of the tools: PHP has been around
longer and has more users. If you want to measure like that, you should be
programming in Java, not PHP.

The number of projects attempted and failed with a given toolset is a much
better indication of its suitability than overall popularity. Even that can
fail though. I suspect a greater proportion of Rails projects succeed than
PHP, but I don't think Rails is the reason in a direct sense. I think the sort
of people who choose Rails are more likely to succeed than those who choose
PHP.

~~~
jamongkad
" I think the sort of people who choose Rails are more likely to succeed than
those who choose PHP."

I'm sorry I don't quite get you here. Could you clarify this statement...cuz
it sounds a hell alot like the elitist BS that is being peddled around by
Rails fan boys as of late.

------
jamongkad
He used MVC and DRY practices not common in PHP but is still very possible(I
know I use them). Very nice! I would give kudos to Martin Fowler's Active
Record pattern which can be found in (phpclasses.org). Very nice library and
easy to use as well. I'm willing to wager the author is taking advantage of
PHP5.

~~~
henning
He mentioned using a feature only available in PHP 5, so yes.

PHP definitely can be used in a reasonably professional way, you just won't
get a lot of examples of it being used that way in books or in code you'll
come across on the Internet, usually.

Probably most of the people who know how to use PHP as well as it can be used
work at Yahoo.

~~~
jamongkad
Sadly that's true. There aren't many good examples of using PHP the
professional way. That being said I can somewhat relate to the author(coming
from PERL/PHP jumped to Rails and back to PHP). I loved the way Rails was
constructed and how it approaches web app development not to mention. I
definitely think most web development frameworks should take a page off it's
book.

------
omouse
So use some other framework for Ruby. Why would you switch languages because
of one framework??

------
Zak
This is yet another article comparing a framework to a language. Aside from #2
and maybe #4, his points would be equally valid comparing Rails to Ruby
without a framework. Only #4 is an argument against starting a new project
using Ruby, and I think it's a bad one; programmer time is almost always
orders of magnitude more valuable than machine time.

Edit: I took a look at the site in question. It's simple, fast and mostly
well-designed, but the fact that it required 12k LOC and 2 months when he had
the best possible functional spec (a working, but internally messy old
version) doesn't give me much faith in his abilities or recommendations.

------
kajecounterhack
I've never tried rails. But I know that PHP can get messy, and if Rails does
clean it up I wouldn't say that rails cant do anything that PHP cant. Because
clean code is something that enables faster development (theoretically
speaking) and more innovation. Of course, probably each has its own use. In
some cases the scale gets unbalanced, it can happen.

------
dappelbaum
I am a better coder now, thank you for reminding me.

------
emonk
switch to django is best ;)

~~~
rkabir
care to tell why?

~~~
emonk
because is easy and powerfull less code and more app

