Ruby on Rails vs PHP Comparison

A comparison of Ruby on Rails (Open Source) vs PHP (Open Source), Performance, Cost, Scalability, Support, and Complexity

by Joseph Montanez

First, let’s try to understand why you want to choose a specific technology. All technologies thrive off the community, tooling, libraries and applications. As a business owner, you may want a technology that will last for many years beyond the project's inception. As a developer, you want a technology that will stay around long enough, so you can get a return on investment. Business owners or developers will often base their decisions on their colleagues and community depending on which technologies are highly advocated. In this article we will go over the pros and cons of PHP as well as Ruby on Rails. We will touch on how PHP and Ruby on Rails compares with common topics such as scalability, maintenance, performance, costs, and support.

Apples VS Oranges

Comparing PHP to Ruby on Rails is not fair. PHP is far more popular than Ruby on Rails, only because Ruby on Rails is a web framework, not a programming language. Ruby is the language behind the Ruby on Rails framework, and PHP is the language used to write applications. Ruby on Rails is comparable to Zend Framework, Codeigniter, Laravel, Symfony2, CakePHP and many other PHP-based web frameworks. So to understand why there is so much popularity with Ruby on Rails, it's better to first visualize people’s searches.

This Google Trend graph shows that all PHP web frameworks still do not amount to the number of searches performed for Ruby on Rails (in blue). In fact the only web framework that is growing in the PHP world is Laravel. So then why is Ruby on Rails so popular?

Well, a big part of building a web application is deciding what libraries you will use, how to organize your application, and many other factors. To date, many PHP projects still do not use a mature, proven web framework. Many PHP developers would rather create a new PHP framework, rather than use the popular frameworks such as Zend Framework, Symfony2, etc. due to the complexity of an application, as with any frameworks you’ll spend a lot of time learning how to use it. Thus, Ruby on Rails tries to simplify the learning process of its framework by utilizing conventions over configuration — in other words, you (the developer or business owner) have little to decide on when it comes to running, organizing or even hosting the application.

This may seem like a good thing, and for the most part, it truly is, which is why Ruby on Rails is so popular. However since then, many PHP web frameworks have recognized this, and are following the developmental steps of Ruby on Rails. This could be why the Ruby on Rails' community growth has stagnated in the past few years. Now while the other web frameworks are shown as a small percentage, you'll still need to keep in mind that PHP is web focused. So just about everything you write in PHP will run on the web, while in Ruby, you will have little choice what code you can write to develop a web application.

I. Scalability and Ease of Maintenance

Whether it is PHP or Ruby on Rails, both have the ability to scale. However, because of the amount of resources Ruby uses versus PHP, scalability issues will arise much earlier in your application’s life cycle. Scaling an application in Ruby on Rails versus PHP will touch on very common issues. Thus scaling will be based on how the application was designed. There are also services online to help resolve scaling issues such as using Amazon Elastic Beanstalk, or Rackspace Cloud Sites. The situation becomes very different when you go from wanting to scale, to needing to scale. When a developer does not have the experience to scale an application, then the most common route is to find online articles, tutorials and other resources to learn. So when it comes to scaling a website, there are plenty of resources written for PHP developers while Ruby on Rails has a much smaller pool of information.

As far as ease of maintenance, this depends on the organization of the application. As long as the developer is using a web framework, then the maintenance overall will become easier. PHP offers a massive selection of web frameworks, all designed for specific goals, while Ruby has a much more limited selection (other than Ruby on Rails).

II. Performance and Speed

Given that PHP is a language, and Ruby on Rails is a web framework, you’d have to take performance with a grain of salt. The point of using a full web framework is to gain productivity at the expense of speed. So let’s put some perspective on this.

Here is a chart of a very simple "hello world" application. Below you can see just how fast pure PHP is when it comes to requests — remember, it’s a language designed for the web. However, once you start to introduce the popular full stack web frameworks, the performance drops, and the requests per second gets closer to the Ruby on Rails number. In fact, a popular web framework Laravel performs worse than Ruby on Rails. As a result most benchmarks are useless, because there’s so much more to the performance and speed of an application than the language or web framework. For example, the database system, caching mechanisms, and network delays can add a 10x to 100x slow down. So how the application is design is far more important than the language or web framework behind it.

In general, Ruby and PHP are some of the slowest languages to pick from, but Ruby takes more resources than PHP does. With the given performance issues, both languages have taken steps to help reduce the sluggishness that arise in everyday applications. Both languages have several runtimes, their core runtimes, such as MRI for Ruby, and Zend Engine for PHP. Using those runtimes are rather slow compared to other languages. There have been several attempts to resolve these issues. There has been work to run both languages on the JVM, which is what Java uses as its runtime. The reason to run on top of the JVM, is not only speed, but to also utilize everything Java has to offer. However just because they run on the JVM doesn’t guarantee a faster application. There are things on the JVM that run slower. So if you need your application running as fast as possible then there is also Rubinius for Ruby and HHVM for PHP which are designed to run your applications faster, at the expense of limited platform support. For example Rubinius and HHVM do not support Windows. They do not support everything the core runtimes provide, thus you’ll have to change certain parts of your application to ensure it can run on these high performance runtimes.

III. Cost

Scarcity is a fundamental concept of economics. So if you have ten PHP developers for every one Ruby developer, and the role of the project depends on the language, than there will be a clear winner in costs. PHP, due to its heavy competition, has lower prices. As a business owner, if your motive is based on costs then this should be a very helpful incentive. There is the saying, “You get what you pay for”, but it doesn’t mean you have to pay the same amount for the experience on hand. PHP has a very easy learning curve. On top of that many PHP developers are new to programming in general and programming web applications in particular.

On the other hand, Ruby is a harder language to learn, so people who do choose that language already know how to program. It’s very natural to have a PHP developer move to Ruby on Rails, and their experience in the PHP world transfer to Ruby. In fact many Ruby developers were once PHP developers. So why would developers jump to Ruby on Rails? Well this answer would be the same for almost every other programming language other than PHP. In every other language (except PHP) the language will limit you on the code you can write, as well as what is available to use. Thus there becomes a common method of building web applications in that language. For example, C# has ASP.NET, Python has Django, Node.js has Express, Lua has Orbit, and the list goes on. So to put this in perspective, let’s say you had the choice to engage with a massive audience, or be among select professionals that share the same goals. It would make sense that the most renowned applications should be built on the languages that have the largest audience, therefore PHP is the target language. Applications like Wordpress, Drupal, Magento, Facebook, are just a tiny fraction of the many applications available, which are written in PHP.

When it comes to hosting your Ruby on Rails applications, the costs can go up very quickly. You will have a harder time finding hosting that supports a Ruby on Rails application, and the big brand names are not cheap. They start at $40, and quickly jump to $500 or more. There are even some companies that provide free hosting, but will charge a lot of fees when needing to expand your hosting needs. Almost all hosting companies that provide Ruby on Rails hosting will also provide PHP hosting as well. Some of the cheaper hosting providers provide old, outdated versions of Ruby (the language), thus limiting you to older versions of Ruby on Rails. They also run your Ruby on Rails application as CGI which is the slowest way to run your web application.

IV. Support And Resources

PHP has a very large pool of developers and online resources. Ruby on Rails also offers many resources online, but there are a far more resources available for PHP. However, many resources you will find for both PHP and Ruby on Rails, are often out of date or wrong. This is the nature of relying on the Internet for resources. There have been initiatives in both communities to create definitive guides. For example, PHP has phptherightway.com, which will help newcomers avoid common pitfalls, such as security, installation, multilingual, coding practices, testing, etc. While Ruby has a large selection of podcasts, and professional video content.

There are also websites like stackoverflow.com that provide more up-to-date resources. On stackoverflow.com, for every Ruby on Rails question, there are five PHP questions. The most voted question have 480 votes for Ruby on Rails while PHP’s most voted question has 2660 votes. One odd aspect is that there seem to be many more questions about Ruby on Rails then Ruby the language. There are also odd revelations in Ruby on Rails, as it’s more about the movement then the language or code.

In fact, its oddity has gained so much traction, that Ruby on Rails has special niche communities such as railsgirls.com, which is a website designed to help women create online applications. They go around the world encouraging females to get involved in technology. On the PHP side there is also phpwoman.com, which has been around for over 7 years, but lack the viral traction that railsgirls.com produced. And that’s the thing to remember, so much of Ruby on Rails’s fame is spawned from the community, by starting off with very dedicated individuals, it has created something that has such a strong market value. It doesn’t matter that it is slow, or that there are solutions that are better, people see and want to become a part of the community.

V. Time To Deploy

Both languages feature fast development times, due to being an interpreted language. For Ruby on Rails there was the famous video, “Create a Blog in 15 Minutes”, which attracted many web developers from all languages. That video set the bar on what a web framework needs to do, in order to rapidly build applications. Since then, subsequent videos have been produced in other languages and frameworks, like creating a blog in 20 minutes with PHP CodeIgniter. Another thing Ruby on Rails is known for is scaffolding. Scaffolding is the process of generating code based on some known parameters. Scaffolding is a very powerful tool to help get your application to market. FuelPHP provides a lot of similar functionalities that Ruby on Rails scaffolding provides.

VI. Editors And Tools

This is an area where PHP outpaces Ruby on Rails. PHP offers a large array of editors and tools. When it comes to benchmarking, profiling, and debugging, PHP succeeds in just having more options. It is wrong to assume that there is something that Ruby on Rails can do, that PHP cannot do. However there are things that both do well, and both don’t do as well, or may not be accomplished as easily.

Most of the concern about PHP’s limits are related to hosting costs. For example, to do certain things in PHP you need an extension, called a pecl. Many shared hosts will have a handful of these installed, but you cannot install your own. Thus if you did want to install your own you’d have to rely on a Virtual Private Server, Cloud Server, or Dedicated Server, which are just as expensive as Ruby on Rails hosting as it needs the same requirements. So most PHP software that comes from the PHP community must rely on older language features and crippled functionality as they are designed to run in shared-hosting environments.

VI.I BACKGROUND TASKS

A background task is something many applications will want to perform, in order to preserve the user experience by providing a quick response time. They are certain things that could take a very long time to complete. For example if your user tried to delete a large amount of data, the application may want to run that as a background task, and this way the user doesn’t need to wait for that action to complete. There are also different ways to have a background task run. You have threads, which may or may not be a good idea, as you could lock up your entire application. There are also asynchronous tasks, which run but are delayed or may run small parts of the operation at a time. The other solutions include running a task on a different process, server or groups of servers.

For Ruby on Rails, you have Threads out of the box, but there are a plethora of Gems (libraries) to consider that are designed to work with Ruby on Rails. Workling, Starling, Resque, and many others will help you design your application so that you can run a long process, say something like an email, calculation, or even a scheduled task.

However for PHP, the picture is very different. There is an extension called pthread, but it is not designed for a "fire and forget"-type of task, such as an email. Instead you are forced to make a few decisions, which you could do in Ruby on Rails as well. First is to design your application correctly to work alongside a task management system. For example, Gearman is a language-agnostic framework for processing jobs. It hooks into every language and all your application needs to do is communicate to it with a workload, such as an email.

So while background tasks may be really easy in Ruby on Rails, they generally lead to bad performance, or applications that cannot scale. The eventual solution many developers choose is something like Gearman (which can also be used in Ruby on Rails). This just leads to the point of how easy it is to delay a complicated piece of your application onto a later stage, when it does become an issue. The other option in PHP is to keep firing a request to the webserver, and that request will check for a task to do. This is normally run by a time based job scheduler, such as a cron, chronos, launchd, cronie, etc. Time based job schedulers are used the most when it comes to PHP applications.

VI.II TEMPLATE ENGINES

A template engine is a way to create and reuse user interfaces based on dynamic data driven information. There are more than 50 template engines in PHP, not including the fact that you can use PHP as a template engine. On the other hand Ruby only has several useful template engines. In the context of Ruby on Rails, there are only 2-3 template engines that would work well with that framework.

VII Closing

So, just remember there is a lot to consider when building an application and if there is really anything to take away from this article, it’s not that either is a poor solution, it’s just that the language is least of your worries. Here is a quick summary of items you can reference:

PHP Large developer pool Affordable solutions Extensive knowledge Diverse selection of tools Easy to Learn

Ruby on Rails Quick to market Easier to find skilled workers Passionate community Ever changing