PHP vs Ruby – Application Shelf Life

PHP Logo

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.

Ruby on Rails – Rotted on the vine

First of all, I want to start by saying that even though we’ve made the decision to switch from Rails back to PHP, I’m not bashing Rails. We still love and develop our WordPress e-commerce platform which is a huge Rails application. I’m just pointing out some of the hurdles we’ve had to overcome – especially with the consulting side of our business – and how switching back to PHP has helped us both with consulting projects and with our own new apps.

Back in 2008 we built a web app for consulting client. Being a consulting project, the plan was to implement the application then hand it over to the client. After handing over the finished project we were not going to be involved with the app – at least not on a day-to-day basis.

The app was built using the current version of Ruby on Rails which, at the time, was version 1.1. We built, tested, and deployed the app – complete with a cluster of mongrels – and handed it over to the client. Everyone was happy, we got paid, and started working on other consulting projects. From time to time we were contacted about minor updates, but when Rails 2.0 was released the client chose not to upgrade. No new end users features or benefits were going to be realized by the upgrade and the client didn’t want to pay the costs to rework a bunch of stuff under the hood. The problem was exacerbated even further when Rails 3.0 was released.

Jumping forward to today, they still have a Rails 1.x app and their hosting company contacted them saying that the version of their operating system was no longer supported and that they needed to update their server. This created a variety of technical problems with the version of ruby, and trying to get a Rails app that’s over 5 years old to run on a current server OS. In addition to the technical hurdles with the server, trying to find a developer willing to maintain a Rails 1.x app is virtually impossible. The application sort of just rotted on the vine.

Framework upgrades cost money

You can say that the client should have kept their app up to date, but that was not an expense they considered when developing the app and it’s very hard to sell a project to migrate a large app from over version of a development framework to the next. Even when upgrades and enhancements were requested, the extra cost to upgrade the version of the framework was not in their budget. Whether or not it should have been part of their budget is not really the point. The point is it takes time and costs money to keep a development framework, especially one as huge as Rails, up to date.

More than just languages and frameworks

What would have happened if we had built their application in PHP instead of Ruby on Rails? Well first of all PHP is a language and Ruby on Rails is a web development framework. So it’s not a fair comparison at face value. If we had built the application with PHP we would have probably looked at PHP frameworks like the Zend Framework and, perhaps to some degree, would have had a similar problem with keeping the framework up to date.

There’s more to deploying a web application than picking a development language and framework. For example, back in 2008 the popular way to deploy a Rails app was running an Apache server for static content and passing dynamic requests through to a cluster of mongrel processes handling all the Rails stuff. Today, nobody deploys Rails apps like that. So if our client wanted to upgrade their app, it’s more than just keeping the framework fresh but you have to implement an entirely new way of hosting and deploying the application.

PHP applications have pretty much always been hosted and deployed the same way. We’re currently hosting our PHP apps with Engine Yard keeping the source code on GitHub. Engine Yard has a really nice setup for deploying all sorts of apps including PHP applications. I’ll describe our setup for how we do all of this later if you are interested, but the bottom line is, the entire app, complete with database migrations is deployed with a single click. We could have used the exact same setup in 2008 as we are using today in terms of the hosting stack – PHP, MySQL, Apache (or nginx).

Reducing exposure to app rot

To put it all together, the aspects of web application development that contribute to the life span include:

  • Keeping the development language current
  • Keeping the framework (if you use one) up to date
  • Keeping the server operating system up to date
  • Keeping the development stack (how you host and deploy) consistent
  • Finding developers who can work on your application

Using PHP, you can dramatically reduce your exposure to things that rot your app. One of the reasons we have switched back to PHP after over 5 years of Rails development is that PHP apps don’t rot nearly as fast.

I plan to follow this post up with a discussion of development frameworks and where we’ve landed in our attempt to optimize developer productivity with application life span. Even for our own internal applications, we don’t want to spend time (and money) migrating from one version of a framework to another. It would be better to spend that time adding end user polish and marketing the businesses.

Advice for start ups and freelancers

If you are thinking about starting up a web based company or if you are a freelancer or consultant building apps that you intend to hand off to your client, you should pay very close attention to what you need to do to keep the app running after initial development is complete.

If you are building a web application for your self or you have a dedicated team that will always be developing and maintaining your application then a Rails application may have it’s merits. But if you are handing the application off to your client, a PHP application will last longer and will be easier to find developers to maintain.


I think everyone understands, but it is worth mention this in a quick disclaimer. Developers in the Ruby on Rails community tend to be more seasoned and more highly skilled. The PHP community is gigantic and includes seasoned, highly skilled developers also. But, the PHP community also includes a large number of entry level developers. The languages is so pervasive and easy to pickup and run with that it attracts people who aren’t very experienced. Since PHP is so easy to run, host, install, and learn there are a lot of applications written by folks new to the idea of application development writing code that lacks the elegance and organization of more experienced developers. You have to start somewhere and I applaud anyone who is interested in getting into the world of coding no matter what language you pick.

Coming up next

We touched briefly on the concept of web development frameworks. I’d like to go a bit deeper into that topic soon and discuss the merits of frameworks and how we landed on the framework we’ve been using for our more recent web applications.

If there’s anything you’d like to see covered in more detail, just let me know. Until then, happy coding and peace my friends!

P.S. If you’re looking for a good way to stay up on PHP news, consider joining the PHPWeekly newsletter. Take a look at the latest issue to see the cool articles they collect.

7 thoughts on “PHP vs Ruby – Application Shelf Life

  1. Dylan says:

    First off, thanks for the insight. I’m currently building my first enterprise level application and I’ve decided to run with a PHP framework, namely because picking up the basics in PHP is extremely easy.

    I’ve never considered the amount of time I’ll have to contribute to maintaining the project as versions upgrade. Especially if the server environment itself needs upgrading. I was curious to try out the hype of RoR and Django, but I’m happy with the ease of development with PHP.

    Moral of the story is, PHP has meta advantages that are outside of code. One I didn’t consider was “shelf life.” Great insight!

    • Lee says:

      Hi Dylan! I like the way you said it – “meta advantages.” Everybody knows that PHP has some syntax that is a bit wonky at times compared to Ruby. The syntax issues can be minimized with clean coding to some degree. But when you back up and look at your entire project from a business perspective you realize that there’s a lot more to a profitable / successful web app than programming language syntax. As developers it’s easy for us to get swept away with the latest stuff (languages, frameworks, platforms, etc). Most of the time the business owner / client doesn’t care at all about any of those things. They just want to make money on the app they are hiring you to build. A well organized / designed app can be easy to maintain no matter what language you choose. So I’d argue that folks saying that our clients will save money in maintenance if you build a Rails app might not be looking at the whole picture. For example, the cost and availability of Rails developers, the application shelf life, and the cost of the production hosting environment. Another point I’ll be writing about is that often times there are clients who may have employees who could make a few small tweaks to the app themselves if it was in PHP but couldn’t touch it at all as a Rails app. Now whether or not we (as developers) should allow that sort of thing is another issue. But in our experience working with ad agencies they have really talented designers who are familiar enough with HTML to be able to make copy updates, spelling corrections, etc. on their own with PHP apps. Just more food for thought…

  2. Petah says:

    This is exactly why I always try and push for a monthly maintenance fee to cover things like this.

  3. William Notowidagdo says:

    Interesting. When I read your post excerpt, I quickly thinking about Zend Framework. Not as framework but utilize it as a library.

    I am looking forward to your future posts.

    • Lee says:

      I’ll be writing another article about frameworks and where we landed as a compromise between developer efficiency and application shelf life. Thanks for saying, “Hi.” 🙂

  4. Andrew says:

    I think You will same problems with PHP after 5 years. PHP is developing now extremely fast, and i can’t imagine how it would like after 5 long years.

    Besides, over previous 5 years, php dev team has closed a bunch of critical bugs, so I think, every site should have updates one time per year at least to keep site secure.

    The same way changed php deployment. Previous: Apache + phpmod, now its nginx + php-fpm

    I mean, php and ruby is two good languages, but your problem is not in language choice, the problem is in time.

    Good luck.

    • Lee says:

      You are right that PHP is developing quickly. I think you will still be able to host PHP 5.3 and 5.4 apps for many years to come despite the development that is taking place. Hosting companies are notoriously slow to update their PHP installations. Another interesting point I didn’t mention in the article is that I also developed a smaller PHP app for this same client that’s still running perfectly even after all these years. I used Code Igniter and PHP 5.2. There were no meaningful code changes when updating to PHP 5.4. I admit that the PHP app was a smaller scale app, but it is interesting that it was so easy up pick up and drop on a new server. PHP didn’t care if it was running on apache or nginx. Thanks for reading the article!

Comments are closed.