4 ms·

7 reasons I switched back to PHP after 2 years on Rails - O'Reilly Ruby

83 points by luccastera 19y ago

whacked_new 19y ago
... 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_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit... And it's odd that this post has 2 points while being a 404.
- jsjenkins168 19y ago
  Strangely, it went 404 right after I read it the first time. The link must have been changed very shortly after this was posted.
omouse 19y ago
So use some other framework for Ruby. Why would you switch languages because of one framework??
blader 19y ago
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 19y ago
  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.
DocSavage 19y ago
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 19y ago
  Correct me if I'm wrong. But I keep hearing (from the community) that the word "well-documented" rarely showed up next to "Rails"
  - DocSavage 19y ago
    I haven't been on news.YC very long, so maybe that was mentioned as an issue a while ago. When Rails first came out, there was a paucity of documentation. The book "Agile Web Development" came out to meet the need. Now when I go into a bookstore or search through Amazon, I'm shocked by the number of books on Rails and Ruby. Truly amazing. Then there are the self-published outlets like peepcode.com, flexiblerails.com, etc. Rails and Ruby coders are also active bloggers and IRCers. The folks at Caboo.se, in particular, have been working on internals documentation. (http://www.caboo.se/documentation http://www.caboo.se/documentation)
  - sbraford 19y ago
    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.
    - 19y ago
ericb 19y ago
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.
dappelbaum 19y ago
I am a better coder now, thank you for reminding me.
breck 19y ago
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 19y ago
  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 19y ago
    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 19y ago
      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.
emonk 19y ago
switch to django is best ;)
- rkabir 19y ago
  care to tell why?
  - emonk 18y ago
    because is easy and powerfull less code and more app
jamongkad 19y ago
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 19y ago
  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 19y ago
    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.
Zak 19y ago
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 19y ago
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.

83 points by luccastera 19y ago

... 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_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit... And it's odd that this post has 2 points while being a 404.

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

omouse 19y ago

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

blader 19y ago

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 19y ago
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.

DocSavage 19y ago

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 19y ago
Correct me if I'm wrong. But I keep hearing (from the community) that the word "well-documented" rarely showed up next to "Rails"
- DocSavage 19y ago
  I haven't been on news.YC very long, so maybe that was mentioned as an issue a while ago. When Rails first came out, there was a paucity of documentation. The book "Agile Web Development" came out to meet the need. Now when I go into a bookstore or search through Amazon, I'm shocked by the number of books on Rails and Ruby. Truly amazing. Then there are the self-published outlets like peepcode.com, flexiblerails.com, etc. Rails and Ruby coders are also active bloggers and IRCers. The folks at Caboo.se, in particular, have been working on internals documentation. (http://www.caboo.se/documentation http://www.caboo.se/documentation)
- sbraford 19y ago
  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.
  - 19y ago

ericb 19y ago

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.

dappelbaum 19y ago

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

breck 19y ago

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 19y ago
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 19y ago
  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 19y ago
    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.

emonk 19y ago

switch to django is best ;)

rkabir 19y ago
care to tell why?
- emonk 18y ago
  because is easy and powerfull less code and more app

jamongkad 19y ago

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 19y ago
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 19y ago
  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.

Zak 19y ago

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 19y ago

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.