The Future of the Web » PHP vs. Ruby on Rails: Update » HTML, CSS, JavaScript and Ajax Expert Web Developer for Hire

PHP vs. Ruby on Rails: Update
May 15 2007

It's now been six months since I announced I had switched from PHP to Ruby on Rails. Reader Richard Wayne Garganta wrote me to ask:

So, now that you have worked with rails a while - are you still in love with it? I tried it a while back and found out my biggest problem was deployment. I have considered returning to it. Your opinion?

Originally, I decided to start using rails because I was getting bored doing server-side development. I asked myself, why was it so much fun to program in JavaScript, but so boring to program in PHP? I figured it might be the programming language itself that was boring me, so I took a stab at learning Ruby on Rails.

Ruby is a really great dynamic language that is fun to work with (though somewhat tricky to get used to). Rails is a great framework, especially when it comes to using ActiveRecord to simplify working with complex data models. I think that Ruby on Rails is a great way to build a complex web site.

Rails also makes it much easier to set up tests (which I was pretty lazy about) and have separate development and live environments. There's a lot of great solutions to common web development problems that makes Rails a lot more fun to work with, especially on big projects.

Eventually I realised that server-side programming in Rails, while a bit easier and more fun, was still server-side programming. Even though I didn't have to worry about writing SQL and building forms, the types of problems and challenges were basically the same as in any server-side language. I realised that even a new language and framework wouldn't change server-side programming altogether. At the end of the day, I still have a lot more fun coding with JavaScript, Ajax, CSS and HTML.

Lately, though, I've been having a lot more fun coding simple templates using PHP. There's something kind of simple and sweet about making a page dynamic by just by putting a few lines of code in a standalone template. MVC is the only way to build a large site or application that is easy to manage, but if you're doing something simple, it's definitely overkill. It's no surprise that the 37signals and Ruby on Rails web sites run on PHP.

So the moral of the story? Use Ruby on Rails for applications, use PHP for simple web sites, and don't use either of them if your passion is client-side development. :)
Tags: server php rubyonrails programming
View 9 Comments | Add a comment
Comments

1. Frederico Padilha at 12:08am on May 16, 2007

Hi Jesse,

Lately I've been researching about programming languages so I could decide which server side language I would concentrate my efforts on. Also, I've read some experiences like yours in other blogs and I recently made my mind. I chose to keep up with PHP (which I have some intermediate knowledge).
A lot of people say that RoR is really something that simplifies things but many said that if you need to get specific you will suffer more from lack of community and for the structure of the language itselft. The majority of web development companies that I've contact with usually sticks with ASP.NET in the end, they say it's because its cheaper in the end, including cheaper in terms of time lost with server-side scripting.
I chose PHP because I just love open source and PHP is far from any web language in that matter, there are so many open source CMS that you go crazy, and I've evolved my PHP so that I can now understand and change what I need. Now I've bought come books and tutorials to really go deep.
I hate server-side scripting, but to know it well gives me power to really get into open source and do whatever I want without the need to structure an entire site in PHP.
I've done many sites using Wordpress, in the end you don't even imagine that Wordpress code is behind it.
My opinion is that client side programming rules, althought I just fool around with Java, I still love and dominate CSS and XHTML.. In the end every language gets the job done, you just have to identify yourself with it and its benefits and downsides. Now my routine is HTML, CSS, PHP, some Javascript for forms and interaction, Photoshop and rarely some Flash, although 70% of the site proposals that come to me are about Flash sites, today I'm turning them down to learn how to make some really powerfull websites! Although Flash is so fun and actionscript is quite simple for what I usually need!
Well, congrats by the post as always, and by that tut on IBM that I finally read =)!
2. Geof Harries at 1:47am on May 16, 2007

I'd suggest that RoR is not only for applications, but also for big sites, such as those with a substantial user base and complex business logic. PHP can certainly be structured so that it is easier to maintain and add to over time, but too many people think quick 'n dirty is good enough. That is, until the site implodes and trying to get the system to work is way more effort than starting from scratch. The strictness of RoR is a blessing in disguise.
3. Aaron Bassett at 6:34pm on May 16, 2007

Geof: RoR for big sites. O Rly?

It is not a flaw in php which produces "quick 'n dirty" code, its a flaw in the programmers ;)
I'm sure that a programmer could produce just as much bad code in RoR as php...

And as for the 'Big Sites' issue, have you not been keeping up with the problems large sites have been having scaling with Ruby? (google twitter scaling issues)
4. Geof Harries at 4:42am on May 17, 2007

Aaron, I'm not commenting on RoR's technical ability to scale, rather that it forces you to use a framework by default. PHP, on the other hand, does not. That's not to say you can't build with a PHP framework, just that many developers, especially young and unexperienced ones, don't even bother.
5. Jennifer M. at 7:11pm on May 20, 2007

I agree with Aaron - it's the way large sites have been developed. I've seen too many large applications built "quick n dirty" with PHP at first, to prove the model. And then they become monsters because code is tacked on and tacked on and nothing is cohesive. There was no development plan.

At that point, when the code becomes unmanageable, companies (unfortunately) turn to MS because of its rapid dev environment.

I really wish a PHP-driven or PHP-like rapid dev environment would "make it big" and prove that MS isn't the answer for large apps! Look at MySpace-- trying to run on Cold Fusion - HA!
6. I L at 10:33am on May 24, 2007

Jennifer -

MySpace has been running ASP.NET for years.

And Jesse, I'm just popping in to say hi - I'm the complete opposite of you. I can't stand JavaScript. It's the devil!
7. I L at 10:33am on May 24, 2007

*about a year. Sorry. ColdFusion couldn't handle it anymore, and after switching to .NET their capacity shot up a lot.
8. SoftMind at 7:36am on June 16, 2007

Hi,

I am looking badly to start with IronRuby Next month. I need to have best of both the worlds. DotNet as well as Ruby. I am just puzzled with few questions, i hope smeone can just answer it here.

Do I need to learn only Ruby OR ( Ruby + C# ) to take the addvantage of IronRuby.

Will Ruby developers work straight away with IronRuby, without any C# or VB.Net Knowledge.

Can some kindly blog Few PreRequisites, so that ruby dvelopers can get prepared to work with IronRuby when released.

I am just confused, can any one guide me. Plus... where can i read regular progress on IronRuby.

Once i start working with IronRuby, will i get more advantage than RubyonRails or Less Advantages..?

Thanks
9. Jake at 6:24am on June 28, 2007

I disagree with with "PHP for simple web sites". You can use erb (embedded ruby) just the way you would use PHP, but you get the beauty of the Ruby language. It is cleaner and more powerful. Or you can use the Camping framework that was developed for smaller sites.

I used to program in PHP but I started looking around for other options because the language itself is really clunky and it was more than I could take. I am much happier now.

Add a Comment

Your Name Email (optional, used for Gravatar) Website (optional) Comment
Note: HTML tags and entities will be converted so that they are displayed as you type them. This means if you type in <em>, people will see <em>, and if you type <em>, people will see <em>.
What is six plus four? I want to be emailed when others add comments to this page.