Vous êtes sur la page 1sur 9

In todays technology centered environment, there are often clashes between PHP and Ruby on

rails programmers for their language supremacy. People should have a clear idea that PHP is a
language and Ruby on rails is language over a framework. So, comparing PHP Vs Ruby on Rails
wouldnt be ideal one. However, I have tried to provide few insights on this comparison.
Most interesting talks these days in tech world is PHP replaced perl and now it is more likely
ROR would replace PHP. I would certainly disagree with these, as PHP has been built to
overcome difficulties based by programmers in perl. Similarly ruby in rails is built by
programmers after drawbacks in languages PHP, ASP and perl.
PHP growth rate is stagnating for the past few years, whereas Ruby on rails has been growing
tremendously. It is mainly because most developers want to be more sophisticated in their
development.
Below are a few general differences.

Application performance:
PHP coding runs faster than that of Ruby on rails code. However, we can achieve tasks in ROR
with few lines of code compared with that of PHP coding.

Web hosting:
Most of the webs hosting companies do support PHP applications, whereas Ruby on rails would
be supported only by unix based server. Still Control panel for Rails 3.0 framework have not
been implemented. On hosting front, PHP is clear winner. With introduction of Heroku, ROR
applications can be hosted easier.

Testing:
In PHP, testing code and modules is difficult one. However, in Ruby on rails with introduction of
R-spec testing rails code is an easy cake for developers.Ruby on Rails development will be

helpful in creating bug-free application. In CakePHP you can do those testing, with certain code
changes.

Code Structure:
ROR has clear code structure compared to that of PHP.

Frameworks:
PHP has more compatible frameworks like CakePHP, codeigniter and Zend. In Ruby too, apart
from rails there are many good frameworks like Sinatra, vintage etc. Both languages has very
good MVC architectural framework.

Syntax:
Both languages syntax are clear and simple. However, Ruby without ending syntax was not
acceptable many programmers.

Memory:
PHP along with its fireworks utilizes less memory space, whereas Ruby on rails would use more
space. Hence, application based on Ruby on rails would be slower compared to that of PHP.
In the war of PHP Vs ROR, developers shouldnt have any issues in learning both technologies.
You could choose technology depending on resource availability and requirements. Ruby on
rails is gaining momentum and PHP has proven track record of matured programming language

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, lets 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 peoples 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 youll 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
applications 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, youd 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 lets 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, its 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 theres 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 doesnt 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 youll 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 doesnt 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. Its 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, lets 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 PHPs 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 its 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 thats the thing to remember, so much of Ruby on Railss 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 doesnt 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 dont do as well, or may not be
accomplished as easily.
Most of the concern about PHPs 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 youd
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 doesnt 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 languageagnostic 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, its not that either is a poor solution, its just that the
language is least of your worries. Here is a quick summary of items you can reference:
PHP

Ruby on Rails
Large developer pool
Affordable solutions
Extensive knowledge
Diverse selection of tools
Easy to Learn

Quick to market
Easier to find skilled workers
Passionate community
Ever changing

Vous aimerez peut-être aussi