Php vs Ruby on Rails Performance Cakephp

May 07, 2012, by admin

Asking some developer which language they prefer between PHP and Ruby on Rails will always get you a quite fine divide, once you get past the fact that you are comparing a language, and a language and a framework. You’ll find that each developer has their go-to language and will protect them till the death.
PHP has been around since 1994, and was built first and foremost as a server-side scripting language for web development and dynamic content. PHP code was originally embedded within the HTML code of a page to allow the content to change depending on the needs of the coder; this has changed more so now with the entry of frameworks into the development world. This file, with a mix of PHP and HTML, was then delivered through the PHP engine to pure HTML and passed back to the browser.
Ruby was born in 1993, and first publicly released in 1995, as a scripting language to be more powerful than Perl and more object-oriented than Python. Although older than PHP, Ruby didn’t really come of age until 2005 when it started to gain interest with ties to the Rails framework. Ruby on Rails was brought to the life it knows today and has been gaining ground ever since.
There really is no real apples-to-apples comparison of PHP to Ruby on Rails.
Since PHP is a separate language, and Ruby on Rails is a language coupled with a framework, you can only look at the common differences. With PHP, you can add a framework like CakePHP, which allows for a more fair comparison.
There are a lot of different areas that can be evaluated within the languages themselves:
Performance
It is said that twenty lines of PHP code will run faster than eight lines of Ruby code. With this being true, you have to ask yourself then, is it worth writing 70% more code for a little speed gain? When you look at the overall picture, less code means less bugs and problems to possibly fix as well as much easier continuation of the code base down the road.

Community sustain

With Ruby on Rails only starting to increase more support out in the developer community, it is without a doubt in my mind that the amount of PHP support out there easily dwarfs Ruby on Rails for support. Over time, however, these tides could very well shift and, once Ruby on Rails is more formally accepted by the developer communities online, we can suppose to see more support groups coming around.
This also applies when you talk about exterior additions for each given language, such as additional libraries for PHP vs. Gems for Ruby on Rails. There is far more support for the PHP libraries based merely on the length of time PHP has been in use, as well as on the size of the support community.

Server Support

PHP is one of the most sustained web programming languages, and as one would imagine, with that much support, the hosting accessibility for PHP would easily rule Ruby on Rails hosting. Now with this said, Ruby on Rails can run on any cPanel-based Unix hosts (which are common), although with the recent release of Rails 3.x, cPanel has yet to be able to execute the support for Rails 3.x on their platform.
This is a very large problem for Ruby on Rails developers.
Most developers, have a server host out on the Internet that they use for testing/playing/hosting their family members’ websites. Most of these will eventually be the cheaper shared hosting plans or reseller packages. The only real solution to this is to get some sort of contributed server where you can get rooted and host your Rails 3.x applications from this location. This is an additional cost to your expected existing hosting, and will most likely be why you never really launch any of your “playtime” Ruby on Rails applications.
Keeping in mind everything you just read, I have been a PHP developer for over a decade. I absolutely adore working in PHP. However, I have a bit of inner confusion.
My introduction to Ruby on Rails at Info-Tech has been a bit of an eye opener to all the things that PHP could do, but doesn’t. I had worked with MVC frameworks, like CakePHP so getting into the Rails segment was a simple translation. However, I had never done any real testing of the code base in PHP. With Ruby on Rails and Rspec, we are able to test all the parts of the site and the user experience.
This allows us to be capable to see if any changes, corrections, or additions have had an adverse influence on the existing code. The Active Record interface for Ruby on Rails is nice to work with as it allows you to completely ignore having to write SQL statements in your code. Making your life that much easier is one thing, but by far the biggest benefit to this is if you ever decide to change your database back end, it is a much simpler transition than having to go back through all your code and rewrite all your SQL statements. Migrations make maintaining changes between environments simple.
Deployments through a gem like Capistrano are nothing more than a few keystrokes once your deployment scripts are ready to go.
So which is a better language, you ask?
Both? Neither?
Each language has benefits and downfalls. In my eyes, they both should have a place in the heart of developers.