Finding the Framework that Worked for Us
In early 2013, I was hired specifically by Engine SevenFour (then known as rtraction) to help on a big new project for a Fortune 100 client. It was a from-scratch B2B web application for our client’s critical internal use, and we needed a framework. I was coming from a Zend Framework Version 1.x background, and I wasn't a fan of how it let you do anything 10 different ways: it meant that figuring out "the right way" was nearly impossible, because there wasn't one. The learning curve was steep, and I wanted something that would be easier to get people up to speed on. The rest of the team had some experience with CodeIgniter, but mostly Drupal and Wordpress, so I started hunting around.
On Feb 28, 2013, I read Phil Sturgeon's "5 Things CodeIgniter Cannot Do (without a rewrite)."
The post discussed many frameworks, including Laravel, which is made with composer packages. It is inherently pro-community; in fact, it depends on it. And it doesn't reinvent the wheel. It supports PSRs for autoloading, namespaces, coding styles and more. It has built-in support for database seeding and database migrations, and has its very own ORM (object-relational mapper) called Eloquent. On top of all that, Laravel is fully unit-tested, and strives to make testing easy. Additionally, the post was significant because Phil Sturgeon was a core-contributor to CodeIgniter, FuelPHP and PyroCMS, and is a member of the PHP FIG (Framework Interoperability Group). That he left CodeIgniter and FuelPHP for Laravel was a big deal.
The next day, I sent the following email to our lead developer, Zoe:
How much do you love CodeIgniter (CI)?
Would you or do you think others would be opposed to trying a different framework that was built with unit testing in mind?
Parts of CI can be tested, but parts can't, because it was not written with testing in mind. By contrast, Laravel, Kohana, FuelPHP, Zend Framework 2 & Symfony2 are all built with unit testing in mind, and come with their own suites of tests that you can run. I'm a testing n00b, too, so I don't want to have to fight with it any more than necessary, but I do think it's worthwhile trying to do.
They also support more recent versions of PHP than CodeIgniter, and newer PHPs have some great features (traits, closures, autoloader, runs faster, etc).
Also, CI does not support actual modules without hacks like HMVC [Hierarchical Model–View–Controller], which has been known to be slow, performance-wise.
I feel like I'm kind of in a weird position, where as the FNG (frickin’ new guy) I shouldn't push for things, but as a dev with 13 years of PHP experience under my belt, something about CI makes my spidey senses tingle in a bad way.
I'm sure we *could* build what we need with it, but i've read articles (see below) saying the CI community has lost its leader and is kind of floundering, and that development on it has slowed to a crawl. Also, in order to support the newer PHPs, the next version of CI will probably not be compatible with previous versions, which will mean we can't upgrade to it if/when we want to.
If this were a short-term project, I wouldn't worry about any of this, but we'll probably be maintaining & building on this for 5+ years. The time spent learning a new framework is negligible when considering such a large timeframe.
Either way I'll be learning a new framework - I just want to make sure it's one that will grow with us, not stagnate & hinder us. Been bitten by that bug a few too many times.
Anyway, happy to chat about it, or just stfu & use CI :)
In my e-mail, I included a link to the CodeIgniter post, along with a piece called “Why CodeIgniter is Dead”; the second article is no longer available, but this discussion of it remains.
Later that day, Zoe had the idea of looking at github stats to judge how actively the frameworks were being developed, and the number of contributors, which would indicate the likelihood of a framework surviving into the future, and getting popular enough to be able to hire for. This is what she found, listed below from least to most apparent support based on the selected criteria:
1212 stars, 202 forks, 2 pull requests, 2 years of development team: 2 current devs, 3 alumni (1 alumni now uses Laravel)
1201 stars, 245 forks, 0 pull requests, 6 years of development team: approx 18 devs!
3229 stars, 966 forks, 39 pull requests, 2 years of developmen team: 1 dev (33 people online in forum with 28k posts)
Zend Framework 2
3738 stars, 1786 forks, 55 pull requests, 6 years of development team: 100s of contributors + corporate sponsor + community.
6228 stars, 2076 forks, 161 pull requests, 12 years of development team: 13 official devs + corporate sponsor + community.
see: http://symfony.com/about and https://github.com/symfony?tab=members
Zend and Symfony had more stars, but also much more development behind them. Laravel was young, but already had over 3k stars, and it appeared to be the most active repository of the bunch. Google Trends showed that it was trending up.
Laravel’s IRC (Internal Relay Chat) room was full of energetic helpful people. It seemed like a great little—but growing—community. And because it was young, it didn't have all the cruft some of the more “mature” frameworks had.
Then we saw Phil Sturgeon's post "Laravel is Awesome." So we started searching some more:
Marc Mulzer's "12 Reasons You Should Switch from CodeIgniter to Laravel" had a great #1: Easy migration from CI.
From a GChat conversation between Zoe and I later that same afternoon:
Zoe: Built in MIGRATIONS!?
I like this too: "With Laravel, I am changing my approach and will begin to unit test my code" because Laravel makes it very easy.
me: yeah, it's giving me good 'spidey sense' tingles instead of bad ones
enthusiasm is contagious, especially from the creator
ORMs make CRUD & DRY easy, but complex reporting difficult… but you can usually just do direct mysql connections/reads for reporting and not use the ORM for that part. my previous 2 jobs used the Propel ORM extensively. Unfortunately, it required you to run a build script all the time and it really slowed down development/deployment. Laravel's doesn't require that step :)
Zoe: I had a lot of trouble doing complex queries with cake
me: i totally hear that. being able to not use the ORM when you need to not use it is important.
Zoe: You must be able to with Laravel?
me: its database connection info is stored in an array. must be able to access it and create a direct connection if you need to.
this looks pretty cool
$user = DB::table('users')->where_id_or_name(1, 'Fred');
me: i'm just reading the db stuff myself. looks pretty sweet. this is some of the most well-written documentation i've seen in a while.
Zoe: it's pretty good
We pushed for, and got approval to use Laravel. We started reading everything we could get our hands on, and got to work building a new B2B application for our Fortune 100 client. We've written well over one million lines of code on projects using Laravel as the framework.
It’s been almost three years, and the Laravel community has blossomed. According to a SitePoint survey, of 7800 developers, Laravel was the most popular php framework of 2015, scoring roughly 37% higher than its nearest competitor (Symfony2), more than twice as many votes as CodeIgniter, and four times as many votes as long-time king of the framework hill, Zend Framework 2. There are at least two Laravel-specific conferences held each year; one in the USA, and one in Europe. Laracasts.com has become the gold standard in “how to” tutorial websites. Laravel itself has over 43k followers on Twitter. Larajobs.com connects Laravel developers with Laravel work. Over 290 people have contributed to the framework. There’s LaraChat.co, Laravel.io, Laravel-News.com and even the Laravel Podcast. Recently, Laravel became the first PHP project to pass 20,000 stars on GitHub, and if you’re a fan of the Fallout games, you’ll be happy to know that the Fallout 4 server runs on an API powered by Laravel.
Derek Martin is Engine SevenFour's VP of Production and certainly not the FNG around these parts anymore.