Fast summary:

PHP

+ easy learning, probably better for fast prototypes/small projects

– grown language, not coding standards enforced = bad for large projects (upgrade project from PHP4->5 is ugly)

Ruby

– hard to learn and understand (need to understand full stack)

+ OOB implemented from the start, probably better for larger projects

Ruby on Rails vs PHP – The good, the bad

Note – this article was written in 2012. I’ve added an addendum to update the article with latest thoughts on May 30th, 2014 at the bottom.

I’ve been developing with PHP since version 2 (a very long time ago). I had been wanting to get into Ruby on Rails and had played with it since version 1 but never had the chance to really use it in production seriously until this past year with Ballistiq. Since then, I’m now coding 80/20 Ruby on Rails and PHP, so I’ll give my thoughts on the two. At the time of writing, the versions I’ll be talking about are PHP 5.3/PHP 5.4 and Ruby on Rails 3.2 (running on Ruby 1.9.3). The context of this post is comparing the two specifically for web development.

Aren’t you comparing apples to oranges?

Yes.

Rails is a framework for Ruby. PHP is a language and has many frameworks. What I’m mostly comparing is my experiences working with both ecosystems: PHP + framework (there are many) vs Ruby + Rails (the predominant framework). While some may get hung up over trying to compare the two and may balk at the title of the article, this is a legitimate question that many developers ask. Many developers want to know what are the benefits/shortcomings of both ecosystems and genuinely just want a clear answer. From the popularity of the article via Google, it’s something that tens of thousands of people actually are asking.

Isn’t it just a preference?

Yes and no. Both the PHP and Ruby ecosystem are very powerful. In many cases, yes you can just boil it down to a preference. However, there are many strengths for both and it’s useful to be able to compare them in a level-headed fashion. I’m not religiously attached to one or another. I’ve used both. My company works with both. Both are here to stay and play important roles in the global web development industry.

PHP – The Good

Simplicity and Learning Curve

What I absolutely love about PHP is its simplicity and relatively shallow learning curve. When you first get into PHP, all you need is a single HTML web page. Change the extension to .php. Throw in some inline PHP, run it on a PHP web server and off you go. It’s really dead simple for someone totally fresh to get something usable done and deployed within a few minutes. This has been one of the strengths of PHP and why it’s so darn popular — designers and non-coders can be productive right away.

This simplicity, however, comes at a cost. It is a double edged sword as it leads to a lot of sloppy, unmaintainable code. This leads people to use frameworks that force a particular coding standard. The benefit of PHP’s simplicity and shallow learning curve is a really big thing going for it and this has business benefits too: it’s easier to find people who know PHP. If you look around, Ruby on Rails developers are more expensive and harder to find. The good developers who really know Ruby and Rails (the L33T) tend to be more hardcore devs.

The documentation for PHP is also fantastic. I find the docs for PHP far more useful than the ones for Ruby and the Rails Guides. The user comments really help and there is a lot of example code that shows you how to solve common problems.

It’s Made For The Web

One big thing about PHP is that it really is focused entirely for the web. It’s not a general purpose programming language like Ruby (or Python/Java/C/Perl/etc.). Many of its inbuilt functions are specific to solving web problems and this makes it a very straightforward language to program for the web. E.g. if you want to send a header to the browser, just use the header() function. An MD5 or SHA1 hash is simply md5() and sha1(). It’s not as straightforward to do this with Ruby/Rails as you have to load in libraries and use namespaces/modules to get to the same functions.

Lot’s of Resources

PHP has a ton of resources, frameworks, applications and libraries available for it. From CMS’ like WordPress and Drupal to frameworks like Symfony and libraries like Doctrine, PHP really has a lot of good resources available. When it comes to deploying a simple CMS, for example, I almost always default to just using WordPress instead of building a Rails app for it. I just feel that it’s a much simpler solution.

Dead Simple to Deploy

Deploying PHP is dead simple. At its simplest, you just FTP the files to a web server (which we at Ballistiq never do – we deploy using Git). Thing is, with PHP you don’t have to know about or care necessarily about the web stack. Many hosting services just use a LAMP environment (Linux, Apache, MySQL, PHP), so as long as your files are in place they just run and that’s that. Even using a framework like CodeIgniter is relatively simple as you don’t ever need to use the command line — you just copy the entire framework directory onto the server and run. That’s it.

PHP – The Bad

Its Evolution Led to a Lot of Bad Code

This is not a direct feature flaw of PHP, but is the result of years and years of building on top of a simple scripting language that was specific to solving simple web problems. PHP was not always Object Oriented. Even when it did support OOP, for years it was not really OOP (missing important features like static methods), so programmers got around the problems through all kinds of shenanigans like using global variables or setting a local variable using a global reference pointer.

E.g. Typical pre-PHP5 code

//Ex1 Using global variable to get reference to database handler
function getPost($post_id) {
  global $DB;  //Stick global variables everywhere in code
}

//Ex2 Using reference - pattern used in CodeIgniter
class Post {
  var $singleton;

  function Post(){
    //Returns a reference to a singleton object
    $this->singleton =& get_instance(); 
  }
}

These are just a couple of examples, but there are more which I won’t go into here. It’s unfortunate but is just one of the side effects of working with a language that has evolved rapidly.

One thing that drives us crazy at Ballistiq is going into projects where we have to upgrade or maintain applications written with old PHP. This is the case with one of our largest projects where we’re trying to upgrade a large app written in PHP4 code and it is horrific. A lot of sloppy code there that we have to work with.

Better Coding Standards Lead To Really Purist Code

As mentioned above, sloppy code is not an inherent feature flaw of PHP. It’s just how people have used the language. As PHP has gotten more popular, it’s gotten a lot of influence from enterprise developers who take a really purist approach to programming. When you go to conferences and listen to these PHP experts talking about best practices, PHP no longer becomes fun to program. You’re almost looking at a Java program. Classes explicitly declare namespaces, importing namespaces, explicit getter and setter methods, explicit declaration of public/private methods, etc. The code becomes extremely verbose. Now If you want to see a framework that takes a more purist approach to things, check out Symfony. It’s a great PHP framework that’s ready for enterprise level usage but from a development point of view, I find it tedious.

Ruby on Rails – The Good

Mature Framework

The more I develop on Rails, the more I really appreciate and love it. I’ve found that it enables us to create higher quality products for clients much faster, that are more maintainable. It’s a mature and stable framework that many large companies are comfortable with introducing into their environments. Compare this with the PHP ecosystem that has many frameworks — there’s a risk of selecting a framework and finding that it’s just not that well supported several years from now (we made this mistake).

Speed and Development Joy

I absolutely love working with Rails because as a development platform, it is extremely automated. So many menial tasks have been automated so that you just focus entirely on solving the business problem instead of hacking your way around a framework. Some things really going for Rails in this regard are:

  • Generators/Scaffolding – Provide a very good starting point for developing around. Some PHP frameworks now provide scaffolding features.
  • Gems/Plugins – the Rails community provides a wealth of plugins as Ruby Gems that you simply add to your project Gemfile and install. This significantly accelerates development and maintenance time as you’re not trying to integrate disparate libraries, it’s already done for you.
  • Active Record ORM – Of all the ORM’s I have used (for PHP I’ve used DataMapper DMZ, Fuel/Kohana, Doctrine), ActiveRecord in Ruby on Rails is simply the best. It actually works and is remarkably straightforward to use.
  • Integrated testing tools – I love it that out of the gate, Rails has a testing framework that can be used. In PHP, many frameworks have only recently been trying to integrate PHPUnit, to varying degrees of success.

As a programming language, Ruby is really quite an amazing language. Unlike PHP, it really is Object Oriented from the ground up. Its code is very concise and powerful. Gems (extensions) enable you to bolt on needed functionality. After coding in Ruby, I find coding in PHP (or anything else really) rather tedious.

Ruby on Rails – The Bad

Steep Learning Curve

My main beef with Ruby on Rails is that it actually has a steep learning curve. Do not believe the hype that says that it is really easy. They will show you podcasts where you build a simple blog application using scaffolding and voila! Instant website. Nothing could be further from the truth. Rails is seen to be easy because they have automated many things in the framework — this does not make it easy to understand.

Developing a Rails app and deploying it actually requires you to know the full stack. With PHP, you can just cobble together some inline PHP code, FTP it to a server and off you go. In Rails, you really need to know what you are doing from the web server (Apache or NginX), setting up Phusion Passenger and database engine. Then you have to deal with the asset pipeline process to prepare your app to run in Production mode. It’s not as simple as running it in production mode — you have to precompile your assets and make sure files are actually there. If they are not, Rails will simply blow up and you have to find out why by accessing the Rails logs.

Compared to PHP, Rails is also unfriendly when it comes to errors. With PHP, it will spit out errors at you in development and the error messages actually make sense. Typically a page will render but the part with the error will show you which line the error occurred and the message is useful. In Rails, typically the whole app blows up.

One last thing to throw in is that good Ruby on Rails developers tend to be polyglots. They are able to pick up and learn many languages. While beginners are battling to just learn Ruby, Rails people are using CoffeeScript instead of Javascript, SCSS (or LESS), and Slim or HAML. For a newcomer to Rails, part of the steep curve is not just learning Ruby and the Rails framework, but all these other languages as well!

Ruby is not an easy language

I’m sorry to offend some people here, but Ruby is simply not as straightforward as PHP to learn. It is by all intents an extremely powerful language. I choose to use Ruby simply because as a developer I feel it is a much better language than PHP. But from a learning perspective, it is not.

Ruby has many features that are simply not straightforward for a beginner programmer to understand. One such concept are blocks, procs and lambdas, which Rails uses heavily. The classic Ruby on Rails example I will use is for creating a form:

<%= form_for @user do |f| %>
  <%= f.label :first_name %>
  <%= f.text_field :first_name %>
<% end %>

If you’re new to Ruby, you can be forgiven for saying, “Wait a minute….what’s f?” Yes sir. Welcome to blocks.

Here’s a bit of an extreme example:

(0...8).map{65.+(rand(25)).chr}.join

Even as an experienced programmer, I went crosseyed when seeing the above line of code. It’s very simple actually – generate an 8 character random string.

Another area is meta programming. Here’s an example:

class Client < ActiveRecord::Base
  has_one :address
  has_many :orders
  has_and_belongs_to_many :roles
end

I’ve taught Ruby on Rails to experienced developers and this always trips them up. What exactly is has_one, has_many and has_and_belongs_to_many? It looks like it’s some kind of reserved keyword or declaration as these are not encapsulated in a method. However, in Ruby, ALL code is executed. Every line of code is executed, so has_one, has_many and has_and_belongs_to_many are just methods that execute when the class is declared.

Finally another thing that makes Ruby challenging for beginners is its loose syntax. Let’s look again at the above code. It’s not obvious (to a beginner) that has_one :address is invoking a method because the brackets are missing from the method invocation. In PHP, the syntax is stricter and this makes it simpler for beginners to know what’s what.

As a language, especially if you’re coming in from others such as C/Java/PHP, Ruby is challenging and it will bend your mind. Once you’re up and running though, it’s fantastic and many who have taken the leap really enjoy coding with it.

Conclusion

So from all of that, what do I conclude?

PHP is a friendlier entry point into web development than Ruby/Rails. It’s easier, there are more resources available and you can get results fast.

Despite this, I personally enjoy working with Ruby and Rails more than PHP. For many of the reasons I’ve described in this article, I just feel that the Ruby ecosystem offers a superior toolset for developing applications. I respect that the die-hard PHP fans won’t feel the same way – that’s cool. My opinion has formed from working with both languages and ecosystems thoroughly in production. Since moving to Rails, I’ve never really felt much of an urge to move back to developing with PHP and so all my new projects tend to be Ruby/Rails.

At Ballistiq, we develop in both.

If a client project already has existing PHP code and we’re developing for that, needing to integrated at the software level, we stay in PHP.

If a client needs a brand new application, or we are building our own app use Rails.

Addendum – 30 May 2014

Wow it’s been a while since I wrote this and it continues to be a very highly ranked article on Google, which attracts a lot of traffic. Because technology advances at such a breakneck pace, I wanted to update this article with some new thoughts.

PHP has come a long way since I wrote this article

When I wrote this article, PHP was in a bit of a transitory phase as many folks were still using PHP 4 and trying to migrate to 5. Symfony 2 had not yet been released, and Laravel just was not a big thing. As of right now, PHP is having a bit of a renaissance. Here are some great technologies that really make PHP shine:

  • Laravel – As a framework, Laravel looks really excellent and many PHP folks have chosen it as their framework of choice. I can’t speak for it because I haven’t used it in production. But it does look good.
  • Composer – Composer is to PHP what RubyGems + Bundler is to Ruby. It does package management that doesn’t suck. For years the PHP community had to deal with Pear, which really didn’t gain much traction.
  • PHP web server – For the longest time, developing with PHP on your computer meant that you had to rely on an external web server like Apache. Many devs ended up installing MAMP. As of PHP 5.4, PHP now comes with its own command line web server, and it’s actually remarkably easy to fire up. Now, not everything works with the command line web server (I had trouble getting WordPress to boot up with it), but if you’re developing with a framework that supports this, it’s a much nicer and saner way of developing.
  • Codeception – One of our team members at Ballistiq gave a really nice talk about a testing framework called Codeception, and I have to say it actually looks decent, supporting things like Selenium and BDD style tests.
  • HHVM – Opensource project led by Facebook, this takes PHP and compiles it to bytecode that in turn gets translated into x64 machine code and runs really fast. This is a very interesting project that makes PHP highly performant and scalable.

So PHP isn’t going away anytime soon. Many people use it and put it to good use.

However, I (and many web engineers) have moved on. As engineers, we’ll hack in anything that we need to get the job done, however, by choice, I won’t start a new project in PHP. Why? I feel that there are more interesting solutions out there that are worth looking at.

Why I still love Rails as a framework and Ruby as a language

As I mentioned back in 2012, I really enjoyed working with Ruby and Rails. Despite it’s steep learning curve, after a while I hit a groove and now the applications that we are delivering are so good that I can’t imagine going back. Here’s some of the things going for Ruby/Rails that I feel really make it such a strong choice:

  1. Gems – When I started coding in Ruby, Gems confused me more than they helped because there was too much ‘magic’. Once I learned that you could (and should) just read the source code for gems, everything made so much more sense. Due to the pluggable nature of gems and the community’s standards, gems can give your application a tremendous amount of functionality very quickly. Some gems that I cannot live without: Devise (authentication – handles user logins, social sign on, forget password workflows and so much more), Paperclip (file uploads – even handles uploading to S3, image cropping/resampling), Simple Form makes forms incredibly simple to standardize and render on websites.
  2. Mountable Engines – We did a mammoth project for a Fortune 500 company where after building the initial application, it was so successful that other departments wanted the same application, but with slightly different functionality and different UI. Rather than copy/pasting the application and having to support several codebases, we were able to extract most of the core functionality into a Rails mountable engine, and literally have one codebase but several websites. The client was absolutely thrilled with this and it was a huge win for us.
  3. Scaling – Rails has a stigma of being unable to scale and they are referring to Twitter dumping Rails. We have not found any scaling issues with Rails and we have applications that run with millions of pageviews and hundreds of thousands of users each month. The fact is, majority of you will never have the scaling problems that Twitter had. And…in fact, we found it easier to scale with Rails than with PHP. How? First of all, Rails supports caching out of the box. You’re able to do view fragment caching within your application code and use Redis as a cache store. That is a far simpler solution than trying to use Varnish which caches everything that goes through it and leaving logged-in users without caching. Using built-in Rails caching enabled us to scale easily. Secondly, Rails + Capistrano + Chef makes it very simple to scale to multiple server environments very quickly. Our typical Amazon AWS infrastructure includes Elastic Load Balancer, several application server instances + a redis/search server, backed by an RDS database instance. We set up server provisioning with Chef, enabling us to provision a new ready-to-run instance in minutes. Simultaneous deployment complete with data migrations can be done with Capistrano from the command line. Literally, I type in cap production deploy:migrations and everything is magically deployed to all our application servers. Users don’t see any downtime as we have Phusion Passenger Enterprise and rolling restarts.
  4. Background jobs – PHP was designed as a hypertext pre-processor which means that it executes only when there is a web request. Compared with Ruby which runs a process. In Rails, you can easily set up background jobs using Sidekiq or Resque. This also adds to Rails’ ability to scale easily. In our applications, we move a lot of stuff that can slow down requests like emailing users into background jobs. Now, PHP can do background jobs using Gearman but that’s not standardized – you have to install the PECL extension. In Ruby/Rails, background jobs are a non-issue. You just do it.
  5. Rails is BORING – Rails is now at version 4.x. It’s a mature framework. It’s boring now. The cool kids are touting NodeJS these days. Rails is boring because it’s robust and stable. We’ve developed apps in Rails now for some of the world’s largest companies and people in their IT departments don’t bat an eyelid. It’s known that it’s a good choice to build your (robust, enterprise-ready, scalable, performant) application on.

Other technologies that I think are shaping the web

  1. AngularJS – We introduced AngularJS into our client projects earlier this year for two Fortune 500 companies and it was a huge win. AngularJS enables you to build single-page applications that run in Javascript. Most of your front-end logic goes into AngularJS, and your backend simply because an API that serves JSON. Doing this, we were able to build highly performant applications. The user experience is very good with this approach because pages load extremely quickly as the browser does not have to do a full roundtrip request.
  2. NodeJS – I started developing in NodeJS a few months ago and it blew my mind. What NodeJS is very good for is building networked applications. E.g. if you’re building a real-time chat application, you can use NodeJS for that. Due to the maturity of Rails, I don’t think we’re moving off that anytime soon for building large applications, but to add real-time components, I would use NodeJS + SocketIO.

So what should you do?

Web development is becoming incredibly complex. The days of a single developer being able to ship a full application from start to finish are becoming more difficult. Even front-end can no longer be handled by a single hybrid designer/developer who can hack CSS + HTML markup.

If you are just starting out, I still recommend that you start with PHP. You will get results much faster, and this will fuel your growth and knowledge. Jumping into Ruby/Rails as your first language might leave you really frustrated trying to get results – remember, with Rails, you have to know the full stack so it’s not just the language and framework you’re challenged with.

Once you’re comfortable with building bespoke applications in PHP, you can then whet your appetite and start using other technologies like Ruby/Rails and even NodeJS/Express, and you’ll appreciate what these technologies offer. Many of the concepts you will learn from PHP in frameworks like Symfony & Laravel will carry over to other languages and frameworks.

Another reason why I recommend PHP as a great starting point is that it’s very useful to know so that you can hack on things like WordPress themes and plugins. WordPress is so widely used today in business (especially marketing departments) and it’s great to have software polyglots who can work with many different tools and platforms.

The thing that you have to realize is that the Web is not about what language you choose to develop with — it’s about the standards and what it takes to get information in and out of the web browser. It doesn’t matter what is on the server, as long as it spits out HTML and the right JSON data – you can use C for all anyone cares. That’s why there are so many web technologies from PHP to Ruby to Python to .net to Java and gosh Perl is still used (I met a guy that wrote a Shopify App entirely in Perl!).

So there you go. Keep on hacking! :)

Leo

Links:

source & creditz: http://www.leonardteo.com/2012/07/ruby-on-rails-vs-php-the-good-the-bad/

https://symfony.com/

liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!
admin