I wrote an article in 2007 that detailed the differences between PHP and Ruby on Rails as I understood them at the time. I now have 3 years of experience with Ruby on Rails and about 9 years of experience with PHP. This is an update to that article since many things have changed over the last two years.

Before getting into the differences between RoR and PHP, I want to clarify the fact that it's not really fair to compare the two. Really, the language is Ruby and thus this article should be called Ruby vs. PHP. Rails is a framework that sits on top of Ruby and makes a lot of web application development more efficient. Since almost all web application development with Ruby uses Rails, talking about one invariably infers the use of the other. By contrast, much of PHP development is still just PHP; however, there are many PHP frameworks available such as CakePHP that work similar to Rails.

With that said, PHP and Ruby on Rails both ultimately result in the same goal which is to give a programmer the ability to create a web application. Both have a large assortment of features to make it easier to deal with rendering dynamic content on a web browser. That's about where the similarities stop.

PHP is a procedural language, which means that it generally starts at the top of the script and runs to the bottom. When it hits the bottom, it's done until the next webpage is requested. Of course, you can use functions and include files, but ultimately it starts at one point and ends at the last line of code on the page. PHP has some support for objects and classes, but it's not inherent and in my opinion, it's cumbersome and feels kludged.

Ruby is a pure object oriented language. Since Rails inherits all of its functionality from Ruby, it too is completely object oriented. Before I programmed with Rails, I didn't understand why this is cool. I thought of each webpage as the "object" and didn't see the need to use objects and classes to build a website. Now that I've been doing it for a few years, the answer is very obvious. A complicated PHP site ends up spaghetti code. It ends up with a thousand and one functions; dozens or even hundreds of include files, and ultimately becomes a giant mess. I consider myself a pretty good PHP developer and have built several sites ranked in the top 10,000 busiest on the web. For any application that was even moderately complex, it became a mess.

The idea behind object oriented programming is that everything becomes a series of classes and methods within that class. When these classes are loaded, they become objects, and each object is separate from everything else. You can think of it like a factory. The raw material comes in one door, and the finished product goes out another door. What happens inside the factory isn't a concern to the other objects. They'll just keep feeding the raw materials and out comes the finished product. Because of this, you can add additional functionality or change the objects internal code without breaking the rest of the site. In Ruby, everything is an object including a string or an integer. Since even these fundamental constructs are also objects, they can be overridden and extended for infinite flexibility. Because of this, you'll see code that looks like this: 24.hours.ago. Hours and ago are methods that extended the integer class which returns the time of Now minus 24 hours. Because of this, much of Ruby code is very easy to read. You can almost read it as if it's English and this keeps things a lot easier to follow - especially for complicated websites.

Programming in a pure object oriented language keeps the code much more clean. Each piece of code exists for itself and by itself and isn't muddied up with other bits of code and features. It's a difficult concept to explain and thus I recommend trying both out and seeing which method you like better. In my opinion, using OO methodology (object oriented) is the right way to program because it's a lot easier to maintain, debug, and comprehend.

Ideals aside, there are a few functional differences between the two. PHP is faster, has been around longer (and thus there are a lot more open source projects that you can use), is generally easier to configure in Apache, and is relatively light on server resources.

Ruby on Rails is a little bit slower, but has made a lot of improvements in speed over the last 2 years. People used to set up Apache as a proxy, which would pass requests to a bank of Mongrel servers. Mongrel is a ruby-based single-threaded webserver that runs Rails applications well. This setup was a little slower than PHP, but with proper caching, it seems as responsive as a comparable PHP page. I never did any stress tests to tell you how much faster in nano seconds one was over the other as I didn't care to know. What I do care about is how it feels to the user, and both felt about the same. Recently, a new Ruby on Rails server has been launched called Passenger or mod_rails. If you use a different version of Ruby called Ruby Enterprise in combination with Passenger, the code seems as fast as or even faster than PHP. Another thing to consider is that mongrel hogged a lot of memory. I'd often run 2 or 3 mongrel instances per application, and each one would chew up 50-100MB of RAM. Those same instances on Passenger use about 30-40MB of RAM. It also garbage collects so if the application isn't hit for a while, it'll release that memory. Ramping up from a released state adds about a second onto the first page view while it allocates memory and then is super snappy on subsequent page loads. Passenger is also a lot easier to configure in Apache. It's comparable to PHP in complexity. Mongrel was cumbersome to configure.

Since a Rails application is loaded into memory, if you make a change in the code on a production server, you have to restart the application (either Passenger or Mongrel) before your changes will take effect. If part of those changes were database table changes, there's a chance your site will be broken until you restart the app. PHP on the other hand has no such problem because each page load is loading all of the code.

What I do now is use PHP for very simple tasks. For example, if I'm building a static site that needs a contact form to send an email, I'll build it in PHP. I don't want to waste the memory resources for something that simple. For more complicated sites, I'll program it in Rails. I can generally program a feature faster in Rails than I can in PHP. I'll warn you right now though... it took me a lot longer to grasp the Rails concepts. It took me nearly a year before I felt proficient in Rails. It took me about 2 weeks to feel proficient in PHP. Now that I've gotten over the learning curve, I do enjoy programming in Rails better. Perhaps this is because it's something new. I think in reality it's because my code feels cleaner, and there are many little features that make things a bit faster to program. Those same features that are supposed to speed things up can really cause problems if you don't fully understand them. I've run into problems many times trying to debug code that's using a built-in Rails helper function, where it would have ultimately been faster to write the functionality myself. Even still, it's more often that these additional features help save time.

That's a lot to process about Ruby and PHP, but I hope it helps you. I wrote ProSPOTLIGHT entirely in Ruby on Rails so you can see the finished product in action. It's using Passenger with Enterprise Ruby and currently doesn't have any caching turned on.