Back in 2007 I wrote an article titled PHP vs Ruby – Practical Language Differences which drew a fair amount of attention. Now that I’ve been working with Ruby in much more depth and both PHP and Ruby have matured dramatically over the past five years it is time to reevaluate the comparison.
The previous article was primarily centered around the languages themselves and was not a showdown between any particular frameworks. In this review we will touch a bit more on frameworks, but in the context of a high level review of the two different landscapes of PHP vs Ruby for web development. We will not be getting down to feature-by-feature detail.
The History And Purpose Of PHP and Ruby
It is interesting to note that both PHP and Ruby both came onto the scene around 1995. So the claims the Ruby is a “more modern” language is not really true chronologically. The major differences between PHP and Ruby have to do with their purposes when they were created. PHP was designed to be an embedded scripting language to provide some dynamic functionality to otherwise static web pages. Ruby, on the other hand, was designed to be a scripting language like Perl, but more readable and expressive. It was not until 2005 when Ruby really found its way onto the web thanks to the popular Ruby on Rails framework.
Knowing this little bit of history about the languages really sheds light on their differences. PHP was not originally intended to be a full-blow, object oriented coding language. Instead, the code was embedded in HTML files and engineered to solve web specific tasks. Therefore, PHP did was not originally designed to have things like classes, namespaces and exception handling. All of those things were added on as the language developed. Ruby, on the other hand, was designed from day one to be a fully object oriented language and to make programmers happy. This also explains why PHP has a somewhat inconsistent set of parameter sequences and function names like the notorious needle in a haystack issue while ruby is very concise and consistent.
// Find the first occurrence of a string
if(strstr($haystack, $needle)) {
echo "The $haystack holds this $needle";
}
// Find an element in an array
if(in_array($needle, $haystack)) {
echo "The $needle was in this $haystack";
}
// Should we separate words with underscores?
in_array($needle, $haystack);
htmlentities($string);
money_format($number);
stripslashes($string);
Web Framework Overview
Web frameworks have come a very long way in the five years since I last reviewed PHP and Ruby. PHP and Ruby are both programming languages. Ruby has a clear winner in terms of popularity when it comes to a framework, so much so that many people do not even know about Ruby apart from Ruby on Rails. PHP, on the other hand, has more frameworks than you can shake a stick at.
Ruby does have another light weight framework called Sinatra. Sinatra is what folks in the PHP wold refer to as a “micro-framework” while Rails is a complete MVC framework. Ruby on Rails and Sinatra are clearly the two main Ruby based frameworks. If you are building a relatively small application like a personal blog or something you may go with Sinatra. If you are building a large application you would go with Ruby on Rails.
We currently do not have any Sinatra based applications in production but we do have two Ruby on Rails applications out there. Mijireh is our e-commerce service for accepting secure credit card payments on a hosted checkout page that looks just like your own site. You get all the PCI compliance, and security benefits of using an off-site checkout service like PayPal or Google Checkout and you do not have to give up the design of your checkout pages. Mijireh is a Ruby on Rails application and there are a few WordPress E-commerce Plugins that integrate with it.
CloudSwipe builds upon the Mijireh concept and offers a complete WordPress e-commerce solution. We developed a WordPress e-commerce plugin of our own to go along with the CloudSwipe platform. CloudSwipe handles products, digital products, shipping, taxes, coupons, promotions, etc. All the stuff you would expect in a comprehensive e-commerce solution.
PHP has a large number of web frameworks available. As I previously noted, my favorite PHP framework continues to be the Fat Free Framework. I was first drawn to the Fat Free Framework (also known as F3) because it was very light weight (like Sinatra) and was very easy to expand with my own PHP libraries.
I am very happy to see that the PHP community is beginning to shift towards building reusable libraries that are not framework dependent. What ruby gems are to Ruby, Composer and Packagist are to PHP. Here is great article titled Packages: The Way Forward For PHP. The idea is that Composer is a package manager that tracks local dependencies in your PHP projects. Packagist is the main Composer repository bringing together a huge supply of PHP packages that you can install with Composer.
One of the reasons F3 continues to be my favorite PHP framework is because it is very easy to make use of Composer when using F3. There are other PHP frameworks embracing Composer as well. Here are a few of the PHP frameworks that all seem to be really nice and why I like them.
Slim Framework 2 requires PHP 5.3 or newer and can be installed with Composer. Slim is a micro-framework in the same genre as the Fat Free Framework (or Sinatra for Ruby).
Fuel PHP will be supporting Composer packages out of the box. FuelPHP is a bit heavier of a framework than Slim or the Fat Free Framework. FuelPHP has code generators, database migrations, and a console interface all built into the framework. All very nice features, but this move Fuel more into the realm of Ruby on Rails style frameworks. It’s going to take some time to learn your way around, but it can do some nice things.
Laravel is the new framework getting all the attention right now. I particularly like how Unit Testing is baked right into the framework. This encourages PHP developers to actually write tests – something that should be obvious and mandatory yet so often seems to be neglected in the PHP community. As of Laravel 4, (not yet officially released at the time of this writing) it is my understanding that all of its components will be managed through Composer. Laravel is the only PHP framework that I know of (feel free to let me know if this is not the case) where you will be able to lock down certain components by version number while still updating other components in your application via Composer. With Laravel and Composer you will be able to pull in updates without having to manually update/replace the system (Laravel) folder.
Application Development
So which platform do you choose when planning to build your next web application? The bottom line is you can do almost all of the same stuff no matter what platform you pick. It comes down to how easy it is to pull off. For example, Ruby on Rails as a framework, is not all that different from using Laravel, for example. But Ruby on Rails has the benefit of ruby gems which is much more mature and has much stronger community support than Composer has right now. Therefore, the likelihood of you finding the gem you need is higher than finding the package you need in Composer. Also, the tools of Ruby based applications are a little more seasoned than they are with PHP.
Ruby seems to be leading the way with gems for things like Pusher, Resque, SideKick, bugsnag, etc. I am not saying that those things are totally unavailable for PHP. You can do them in PHP too. There are PHP libraries such as bugsnag-php, php-resqueue and there is even an example for using Pusher in PHP. I am just suggesting that the Ruby is a little bit ahead of PHP for these sorts of things. Ruby is leading the way and PHP is playing catch up to some degree. Be that as it may, I still have not found anything that we can do in Ruby that we cannot do at all in PHP.
Web Hosting vs Web Application Hosting
The last piece of the puzzle is web hosting. There is a big difference between simply hosting a website and hosting a web application. If you are looking to host a personal site, like a blog, it is no secret that WordPress, which is built in PHP, is the clear winner. There are far more WordPress sites than all the other Ruby based CMS sites put together. With PHP you just plop your files on the server and you are finished. Theoretically, you can do enjoy the same “upload and go” style hosting of a Ruby web application too using Phusion Passenger. There are very few shared hosts that have ruby support compared to hosts that support PHP. One such host, however is A Small Orange and they do offer Ruby support via Phusion Passenger as well as PHP, Python and Perl. PHP is the clear winner when it comes to hosting a small web application or CMS like WordPress. Or, if you happen to buy an off-the-shelf self-hosted web application like iDevAffiliate affiliate program or the LemonStand eCommerce package it will most likely be a PHP application because of how easy and available PHP web hosting is.
If you are going to be developing a large scale web application or even a medium scale project you will most likely want a more robust hosting solution and will either get your own dedicated server, a VPS, or a slice of a cloud somewhere. As soon as you venture into anything more powerful than shared hosting you will be setting up your own server configuration and will probably have access to install anything you want. For example, if you intended to run Resque for your background jobs you will also need to install Redis. By the time you get to this level of configuring your own server, the general availability of PHP is not really an issue anymore. Just install whatever you want.
Rather than building/setting up your own server you might think about using a cloud hosting platform. Once again this is an area where Ruby has lead the way with Heroku, but PHP has followed suite with PHPFog. Both are excellent, easy to use, very powerful platforms that take much of the hassle of deploying a full-blown web application. To prove my point of the Ruby solutions being more seasoned and established just take a look at the list of add-ons available for Heroku vs the add-ons for PHPFog. If you are interested, here is a more in depth review of Heroku vs AppFog (the company behind PHPFog).
The Conclusion
Concerning the two languages themselves, Ruby is more concise, consistent, and more cleanly object oriented than PHP. In real-world practical use, however, there is not anything you can do in Ruby that you cannot do in PHP. I am not talking about stuff like re-opening classes in Ruby. While you cannot technically re-open a class and modify it on the fly in PHP, you can still accomplish the same end goals, you may just have to approach the problem in a different way. The primary difference between Ruby and PHP is syntactical sugar which many people find very important for programmer efficiency and happiness but in everyday programming scenarios both languages can generally do all the same things.
Here is my score card to to summarize my 2012 year and review of PHP vs Ruby:
- Practical language power: There really is not anything you can do in Ruby that is impossible to do with PHP
(Ruby and PHP tie) - Web Frameworks: Ruby has two primary web frameworks and PHP has a very large number of frameworks fragmented and scattered about. You get many more choices with PHP but because the frameworks are so young they often shift course quickly and dramatically. The two main Ruby frameworks have large communities and while continuing to advance, they are more mature and established.
(Ruby wins) - Code reuse: Ruby gems are awesome and PHP is moving in that direction with Packagist and Composer
(Ruby wins) - Development tools and services: Ruby seems to lead the way with tools and services for developing web applications but PHP is following closely behind.
(Ruby wins) - Local development environment: It is really easy to setup a local PHP development environment (see MAMP and XAMP) and build your own applications.
(PHP wins) - Hosting off-the-shelf applications: PHP web hosting is less expensive, easier to deal with, and more widely available so it is easier to host a PHP application or CMS than a Ruby based one. So if you are building an app that you intend to have people host themselves, choose PHP.
(PHP wins) - Hosting your own application: Unless you are building a really complex web application it will be less complicated to build a PHP application and drop it on a server that already supports PHP than it will be to set up a local development environment for Ruby and deploy your application to a Ruby enabled server.
(PHP wins) - Large scale application hosting: If you are building a large scale project and setting up your own application server(s), it does not really matter how many shared hosting companies there are that support PHP. It is your server and you can install whatever you want.
(Ruby and PHP tie)
Final score: PHP: 5 / Ruby: 5
Closing Remarks
The above little score card is just a reflection of my thoughts and experience with PHP and Ruby. I am personally heavily involved in both PHP and Ruby on Rails development. I am one of the lead developers for the Cart66 WordPress E-commerce plugin which, of course, is PHP and I am also involved with CloudSwipe which includes both a WordPress plugin and a Ruby on Rails powered E-commerce platform. The bottom line, as always, is pick the solution that is right for you and your development team. My hope is that this article was helpful in shedding some light on the strengths of both PHP and Ruby, spreading the word about what is available to both languages, and helping you decide what is right for your next project.
Please leave some tasteful comments with your experience developing web applications with either PHP or Ruby and where you think things are headed in the future.
Great article! I’ve also been working with both PHP and Ruby and have long awaited an article as in depth as this. Few things:
1) Local development – I honestly do not believe there is anything more simple than setting up a rails application and locally developing, however, getting it to production server is a WHOLE `NOTHER thing though. I think ruby should have won over an XAMP environment.
2) Practical language power – I’ve worked with PHP for 8 years and ruby for just under a year now. It could very well be I don’t know enough about the language, but I do think it’s possible to do more with PHP than with Ruby. For example, I’ve written PHP applications that help manage my server activities and tie directly into perl and bash scripts. Again, maybe there’s a way to do it in Ruby but I’ve found it more practical to approach it in PHP.
Just some thoughts 😉
In 1-Local Development, PHP now easily wins.
In the current (awesome) version of PHP 5.4, PHP have a test server wich you can use to test your scripts locally.
Thank you for your article.
I am a C# developer using ASP.NET MVC.
I don’t really know PHP, but I wanted to learn another language too, so I was between these two. PHP or Ruby.
I started out with PHP but then I was really disappointed by the existence of too many frameworks!
Also, I’m really interested in faster development and code reusability.
So I chose Rails. I just started learning.. we’ll see how this goes.
Your article ensures my decision, thank you!
Now this is weird. You mention some obscure, small PHP frameworks and forget to mention the main ones? Where’s Zend Framework and Symfony 2? Their user base largely outweighs any other PHP frameworks out there…
You are right, Zend Framework and Symfony 2 are both very popular frameworks and certainly worthy of mention. I personally tend to work more with the smaller/micro PHP frameworks. I built a gigantic electronic medical record app a few years ago with the Zend Framework and found it to be a very verbose framework with giganticly long class and function names. I didn’t like it very much at all, but it certainly has lots of libraries and thing it can do. I have never built anything with Symfony 2. Thanks for the comment 🙂
I worked with both ZF1 and Symfony2 (and Symfony 1 as well, but I’d like to forget that :p). They both have their (dis)advantages, but I must admit that after working with Symfony2 for a while I can see why lots of PHP Open Source apps are watching it closely (and adapting it as well). Ohm Sf2 is also using composer (since v2.1) and lets you lock bundles as you see fit.
If you want a micro-framework based on the Symfony2 components, you could also check out Silex.
Long class names are out and namespaces are in w/ Zend Framework 2 .
Ah that’s cool. I haven’t done anything with ZF2. My last project was with ZF 1.5. Namespaces would certainly make things much better. Do you like working with ZF2 over other frameworks like Laravel or are you just mentioning the addition of namespaces?
Great post !
There is a typo in link Packages: The Way Forward For PHP http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php it has a comma at the end of url
Thanks for mentioning that, I have corrected the link. Sorry about that.
Hey there, nice article.
I’d like to add 2 little things to it, if I may.
1º – PHP is a better choice when it comes about Windows.
Some of my clients have a Windows workspace, with servers running Windows Server and Clients/users with WIN7.
It’s really annoying to set up a Ruby/Rails enviroment in a Windows. Specially if your clients enforce you to use Microsoft tools, like IIS.
PHP is just a simple step inside IIS.
2º – PHPFog is really nice, but there is a “heroku like” for PHP. It’s called PagodaBox.
I’ve been using Heroku for Python/Django and PagodaBox for PHP.
Both really helps a lot with your development.
Pagoda is focused only in PHP, and it has a lot of features, libraries and addons to help you app to be legendary.
PS: sorry for my lack of english accuracy.
Have a nice day!
Thanks for mentioning PagodaBox. I didn’t know about that. It looks very interesting! This is why I love comments. People you’ve never met introduce you to cool new stuff! Thank you!
Thanks for the very concise article. I was in the process of learning Ruby/Rails before hearing about Laravel framework for PHP. For me, getting up and running on a shared server was important so therefore PHP was the way to go. Your post has highlighted however that the gap between these 2 languages is getting closer and I may feel I want to step more into Ruby at some point in the future.
It is interesting, but if you use PHP 5.4 is very important to be concidered for the comparation with another languages.
Regards
“Ruby seems to lead the way with tools and services for developing web applications but PHP is following closely behind.”
Reeeeeaaaaaaallly ? :)))
Ruby Sidekiq uses Celluloid, which is an Actor pattern for concurrency.
Not sure if PHP will ever have threads.
Ruby and Python still affected by GIL so does not have true parallel concurrency, unless you use Rubinius or JRuby.
PHP style development mostly revolves around processes.
I think the future will be Scala/Akka/Netty vs Node.js vs JRuby/Rubinius/EventMachine vs Python/Twisted
I haven’t heard of anything from PHP when mentioning concurrency or c10k problem
I disagree. Ruby lets you override existing methods in a class, or even change the behaviour of core classes and functions. It’s dangerous stuff but can be extremely useful if implemented carefully and wisely.
You can also mix methods from other classes into your class. You could do that with PHP but you’d have to copy the methods into a separate trait and include that, meaning it’s impossible to automatically update the methods from the original class.
I’ve been doing PHP for 12 years and Ruby for six months and I honestly regret not making the jump to Ruby years ago. The language is far nicer to work with.
The ruby language is clearly more dynamic than PHP is – no question about that. The point I was making in the article, however, was on a higher – project feature – level. That is why I called it “practical” language power. You may have to take a different programatic approach to solve the problem, but PHP and Ruby can both do the same things. I agree that ruby, as a language, is nicer to code with. My point was that for all practical purposes any website built in one language could have been built in the other. A lot of people come to me under the assumption that they HAVE to use one language or the other because they need to be able to (fill in the blank). It’s almost always the available gems/packages or the features in the framework that make the difference, not the language itself.
I used railsinstaller.com setup to install on windows and I was up and running ruby AND rails in less than 5 minutes. For php I use WAMP, which was also super easy, but the you also have to setup/install the framework or your choice (Zend for me). I would have to say its a tie there, or even RoR. Both can be up and running in under 5 minutes.
thanks for arcicle was very use full … I am at the point considering what language to chose for comercial development. PHP seames to be more popular and easier to find programmers, but Ruby seams to be more effective in development…
On Windows PHP fails miserably.
1) The filesysem subsystem is not workable. It fails to work with Unicode file names and require slow complex workarounds (using native Windows services). Moreover, the developers ignore messages about such problems for years.
2) NET extension was buggy for years and is still not fixed (wrong byte array handling which require “fixes” which may be incompatible with future versions).
3) Inability to load properly external libraries. There is a wrapper, but it is outdated and won’t work properly with newer PHP builds.
Really ? Try loading extension script with class names already present in some other, already loaded extension. Try making a class instance generator which also contains class instance generators (possible, but complex, slow and takes way more code to implement). Try opening a file with Unicode filename in Unicode directory on Windows. Also, the integers – ideally they should not depend so much on the platform and result in different results on different platforms – the “developers” usually spread lies about “32 bit and 64 bits” as if the integers implementations have something to do with the register sets be they 1 bit or 1000 bits. For high level languages integer type should be a mere concept regardless of how they are represented at lower levels (implementation level).
Ruby can do some very cool things. I hope you didn’t misunderstand my point so let me reiterate my comment from March 8, 2013. When I said “Practical language power” I was not referring to the technical hoops that you can jump through with Ruby. Of course Ruby is a more dynamic language.
One more thing – even with incomplete and erroneous support for older Windows versions they decided to “drop the support” of those older Windows versions because “they are outdated” – but actually it looks like someone just made up an excuse in order to easily copy-paste some source code with some function used 0,01% of the time without the need to write and support the code himself.
i’ve used with PHP but maybe i’d love something consistent, this article got me.
how about server performance & scability?
can you explain more…
say that they have the best for their own.
There are a few shared hosts that actually allow you to run Rails. I have a Rails 3.2 server running on Bluehost right now. Costs me a mere $80 a year.
To FullMooonMadness: i’m in the exact same spot. Still work a lot with .NET but looking for an alternative to target a wider set of hosters (rupy on rails IS actually available on quite a few bigtime hosters)
I’m not really a fan of PHP so far. It’s just too different from .NET…
what is judgement so far concerning rub on rails?
Ruby is just a perfect beginners language in my mind. I love the language, it in my mind is amazing.
I’ve been developing with PHP for the past 15 years and developing heavily with Ruby for the last 2. For the most part I completely agree with you except for one thing.
For local development, Ruby wins hands down. Above you’re stating the reverse, but it’s incorrect. RVM and Foreman make local development SOOO much simpler for multiple projects.
With RVM, you cd into the directory of your project…and it switches to the correct version of Ruby or jRuby or Ruby EE or Rubinus along with an encapsulated Gemset just for that project. It’s lets you install and update new versions of Ruby as well. If I have 500 projects with different versions of Ruby and different package requirements…it’s not a problem. In fact, I can also have those applications running and talking to each other locally on my own machine. With PHP just having 2 different versions at the same time is a PITA.
That’s before we even get to Foreman. Foreman is kind’ve a way of life in Ruby land, but it’s a tool that can be easily applied on any machine. It let’s you define a simple Procfile with what you would type from the command line to start each piece of your application: web server, background worker, database, memcached, redis, etc. Then you start your entire application by just typing ‘foreman start’. It starts all of them in separate processes, assigns each one a color, and then shows you the output of all of them in one command prompt. To stop your application, you just hit Ctrl + C and everything shuts down.
It’s so smooth it’s sickening but that is one area where Ruby blows PHP out of the water and it is not even close.
With PHP it’s easier to find people that do PHP. It’s just as hard to find programmers. As somebody who spent 3 years running a PHP development company, take it from me that the PHP community is saturated as a mix of really good programmers that know what they’re doing and designers who have taught themselves PHP with no idea what they’re doing.
The litmus test that finally became an effective filter for our candidates was testing PHP candidates on what OTHER languages they know. A self-taught designer will know PHP and Javascript only. A programmer will know at least one of C, Java, C#, Ruby, Python, Groovy, Scala, Objective-C, etc as well as PHP/Javascript.
That became the simplest way for us to filter out the programmers from the designers. Good programmers are hard to find regardless though.
That’s a really interesting idea about asking what OTHER languages a person knows to see if they are a real developer or a designer masquerading as a developer. Great tip! Thank you!
Good point! I’d like to add that there are also some pretty good ActionScript 3 developers out there, even if some of them started out as designers and became hard core devs later (and got paid more in many cases). Large Scale Flex and Flash projects required a well thought through architecture, and there are even AS3 MVC frameworks that mimic Java EE features like code injection. Without decent OOP knowledge you were lost in those projects.
Yet in my experience at the end of the day it is not even the language background that matters most. I’ve written awful php AND C++ code in my early days. I got better at Java once I had learned ActionScript 3 frameworks. I later gave pro trainings for OOP (after also heaving worked though OOP books), yet I learned many new useful things after having done my first real life Rails project…