So you’re starting a new project and trying to decide on your web application framework- which is better? Let me start by saying that there is no “best” option. It comes down to individual project needs, but we’ll try to measure the two as objectively as possible.

So what makes a web framework good?  It’s easy to blur the lines between language and framework, but for this article we’re writing about the framework itself and not specifically about Ruby or PHP.  To make a valid comparison, we’re mostly judging around the following factors:

  • Being able to read and write code quickly without error
  • The ability to configure the framework
  • Reusable packages that make extending easy
  • Stability, scalability, and ability to maintain an application

Language syntax and legibility

To give a quick idea of the differences in language structure, we’ll use two pieces of code that define relationships between models.  In this example, every post should have comments tied to it.  In Laravel this is written like so:

public function comments()
    return $this->hasMany('AppComment');

In Rails, your code would be:

has_many :comments

The second one is not only easier to read and faster to write, but is also easier to remember.  I remember going back a few times to double check that my code was correct the first time I wrote a relationship in Laravel.  With Rails, I remembered from from the first glance and was able to guess how to define other relationships before ever having seen them.

In fairness, Laravel made me enjoy writing PHP again, but when I’m coding in Rails, I don’t miss semicolons and brackets everywhere or Blade syntax for that matter.

Winner: Ruby on Rails

Gems, packages, and community

Gems and packages are a huge part of what make a framework so valuable. They allow you to take reusable components and reduce the time it takes to develop an application to a fraction of the time. For basic items like user authentication or adding tags to your posts, you should not be reinventing the wheel every time.Rails has been around a lot longer than Laravel; it was created back in 2004 while Laravel started only 5 years ago in 2011.  Because of this, Gems are a lot more established and have had time to mature, while some of the packages in the Laravel community seem to be in disarray.  For example, the largest and most followed admin CRUD package seems like it’s barely maintained anymore.  Contributions and commits have dropped to nearly nothing and the front-end is in need of a major makeover in addition to many Javascript conflicts with the Knockout library they’re using.  At the time of writing here are some numbers regarding the activity of this project:

Stars: 1860
Contributors: 60
Last commit: June 23, 2016

There are two major gems that do admin CRUD actions well in Rails- Rails Admin and Active Admin.  Both are great, with Rails Admin being a little more opinionated and easy to setup, while Active Admin is highly configurable.  Here are the stats for comparison of the two respectively:

Stars: 6248
Contributors: 338
Last commit: 8 hours ago

Stars: 6960
Contributors: 487
Last commit: 25 days ago

This is a huge win for Rails.  This kind of stability and community behind a package gives me a lot of confidence that they’re not going to abandon the project and we’re not left up creek without a paddle.  This is something that I fully expect will get better with Laravel over time as it catches up in popularity.


Winner: Ruby on Rails

Server setup and configuration

Laravel setup is a breeze. Most pre-configured servers come with PHP, Apache, and some form of Linux. This means you just have to run your initial build commands and you’re good to go.

composer install

Rails on the other hand, needs Ruby installed (preferably with a Ruby version manager like rbenv) as opposed to PHP. This alone doesn’t make it a worse choice but since most servers just don’t come with the necessary tools out of the box, it does make things a little bit more difficult. This is just a result of most the internet being run on PHP.  According to W3Techs, a whopping 82.3% of the internet is run on php.

With Rails, your setup isn’t too much different:

bundle install
rails server

That second line is what starts the server, but for many reasons you can not expect to do that on a production server.  Rails needs a separate application server like Phusion Passenger or Puma. I really like Passenger and it’s a breeze to setup, but it’s still one more step that Rails takes to get running. And in the unlikely event that it crashes, it may require a manual restart whereas PHP throws an error and keeps on keeping on.

When it comes to application configuration, Laravel tends to be a bit more opinionated.  It comes with a pre-built authentication system for users and the Dotenv library for setting environment variables.  Since these are items I’m using in almost every application anyway, this is a time saver and much appreciated.

Winner: Laravel


Once an application is up, you still need to be able to easily apply updates and provide safe builds for clients.  SSH’ing into a client’s server and pulling your latest repo is pretty risky business and you’re almost guaranteeing yourself some level of downtime between builds even if you don’t make any mistakes.

There are many great deployment tools available that you should be using to deploy.  They handle everything from migrations, to testing, productions builds, and symlinking new and old copies of your application in case a bug does make it through so you can easily revert back with a single command.  Capistrano has been around for quite a while and is available to both Laravel and Rails.  While it works well, I’ve always found the setup to be somewhat exhausting and trying to hack around it to play nice with Bedrock for WordPress was a nightmare.

Rails has a great tool deployment tool called Mina.  It takes a couple minutes to configure and setup and most of my deployments take around 30 seconds to fully test and build out since it only needs to SSH into your server one time.  Laravel has something similar called Deployer, but I have not yet had the chance to test it out and would love to hear feedback from someone with experience using it.  However, it looks like you still need to add a custom recipe for it to work with Laravel.  And the winner by a small margin:

Winner: Ruby on Rails

What do your developers know best?

I strongly believe that the technology used should follow project needs and not those of the developers. But that being said, if you’re tied down to a developer who is faster at a specific language, it may be the better option.

Recently we were contracted to handle the backend for a rather large company. We were deciding between Rails and Laravel. I pushed strongly towards Rails after a long discussion regarding their needs and finding much more stable gems for Rails than packages in Laravel that fit their M.O.  In the end they only had PHP developers in-house who were worried about general maintenance and upkeep and a bit nervous about using a new server environment.  While this is somewhat backwards thinking in managing an individual project, it will probably (hopefully, maybe) yield lower cost for them long run even if they have more maintenance.

Winner: Tie


In my mind, Ruby on Rails is the clear overall winner and the framework I enjoy the most. I came from a PHP background and when I first started learning Rails, within a week was finding myself completing the same code in less time than it took me in Laravel.  Laravel is still a fantastic framework (and in my opinion one of the best if you’re tied to PHP).  Furthermore, the decision on which to use is still largely dependent on project needs and sometimes PHP is the better option.  You can’t really go too wrong with either solution.

The cons to using Laravel can be written off to growing pains and since it’s still a relative newcomer in the field, I hope and fully expect we’ll continue to see it grow and stabilize more over time as the community continues to grow and packages mature.