Our team recently faced a typical (PHP) developer problem: build a simple app in a few days that’s good-looking and feature-rich enough to convince your customers right from the start that you mean business. After all first impressions really do matter. We wanted to find a PHP framework that would let us develop rapidly, while also giving us long-term scope for rich development on a large project. We might also want to use the framework on other projects too. A couple of days of searching, forrsting, and general trawling through the internet and we came up with a couple of prime candidates for a PHP MVC framework – FuelPHP and Laravel. They are in fact rather similar. Children of 2011, both are based on the hugely successful CodeIgniter. They improve on their mentor in a number of ways – often specifically PHP 5.3 (and 5.4) related ways. The heavy use of namespaces and closures are things which spring to mind. We particularly liked Laravel early on because of its clear documentation, and a healthily active community of developers working both on the core and a raft of handy plugins (aka bundles). We also found some particularly good tutorials by Dayle Rees who has even published an ebook called Code Happy with Laravel We found a great little CRUD app on GitHub which seemed a good way to get started with Laravel. It uses twitter bootstraptoo, and looks great! So we went for Laravel.
Simple (and fun!)
The first thing that struck us about developing with Laravel was how simple it was. Our usual experience with big frameworks (you know which ones I’m talking about…) is that you end up spending about a week/month grappling with obscure YAML config settings, unhelpful helpers, fussy syntax, partially documented classes, and a general sense that the framework isn’t in the end really saving you a lot of time or effort. We just didn’t find that at all with Laravel. One of Laravel’s selling points is that it brings the fun back into PHP development. And you think “yeah right, well they would say that wouldn’t they”. And other things along those oh so cynical lines. But our experience was that it really did seem to make development more fun. Laravel provides just enough built-in features that you can focus on the more interesting parts of your app without having to worry too much about the boring basics. So what are these features?
Laravel uses its own ORM, called Eloquent. This is based on PHP ActiveRecord, although I’m not clear at this stage how exactly it differs. But it does work well – and simply – while allowing for more advanced features like eager loading. Unless you have a really crazy schema the chances are Eloquent will work well for you. Certainly the schema for our project is somewhere in between basic and complex, and we’ve not yet come across any gotchas. A project I worked on a year or so ago ended up using key-value storage in a MySQL db. It wasn’t an easy decision. If you’ve ever tried key-value storage with a relational ORM you’ll know what I mean. Mercifully life doesn’t have to be that cruel, and if your friendly neighbourhood sysadmin is having a good day things like MongoDB and Redis are there and ready to serve. My point being? Laravel has Redis support built in. How nice. You can also build your own queries with Laravel’s Fluent Query Builder, or if you really need to you can always just write those SQL queries in the raw like mama used to make. Laravel does come with a handy db migration tool too. It’s not super-sophisticated, but it is useful for running (and rolling back) schema changes. Added to this is the Schema class, which basically lets you very easily create database structure without coding any native SQL.
An important feature of any framework is a community of developers who contribute extra functionality to the core through some form of plugin system. Laravel is no exception. It has just over 80 “bundles” (when I started thinking about writing this post 2 days ago it had 80. Today it has 82. Crazy!) ranging from a scaffolding tool called Bob to a very simple profiler bundle which adds the PHP Quick Profiler to your site. Bundles are hardly at the volume of symfony or Drupal plugins/modules, but it’s impressive work for a framework that barely existed a year ago. Also I’d say from my experience developing with WordPress and Drupal that it’s farbetter to have a few well-maintained plugins than a sea of plugins that worked really well a year ago in version 1.0
I don’t want to downplay the many other features that Laravel has, but there’s little point in describing them in detail here. If you want a really nice outline then take a look at the clean and clear Laravel docs. Basically Laravel has a bunch of features that are pretty much what you’d expect from a framework: form helpers, caching, session tools, authentication, security features… You know the kind of thing, and it’s all good stuff.
What we did
Our goal for sprint 0 (we’re an Agile team you see) was to build the beginnings of a CRUD app to manage University course details. It needed forms for editing courses, LDAP authentication, some role provisioning, and importantly a versioning system that would track all edits and allow rollback to earlier versions of courses. We (3 developers) managed to get from absolute 0 to beyond our sprint minimum viable product in about 40 developer-hours. Most of that time was actually spent planning how the app would work, working out the data model, and generally making it look nice. We spent almost no time at all worrying about how to get Laravel working for us. The whole thing really was great fun! And on top of that our customer was really happy with the result. We love happy customers!
We enjoyed using Laravel. That doesn’t make it perfect, so here’s a couple of things that would be nice. I suppose instead of sounding like I’m moaning too much I should just gitin there. Anyway…
- Documentation. While Laravel’s documentation is really nice, there’s kind of a gap between the getting started stuff and diving headlong into the API (which is itself well commented actually). Laravel is still really young, and the fact that the documentation is as good as it is says a lot for the core developers’ commitment to clarity.
- Behat. Laravel really suits Agile and BDD. It would be lovely if Behat/Mink were included out-the-box in the same way unit testing is. To be fair it’s not hard to get Behat tests up and running alongside Laravel. But still… it’d be a really nice feature.
Some other sites
I found a couple of particularly useful blog posts on Laravel. They seem to come to kind of the same conclusions as me…
If you’re looking for a solid, fresh, new, simple, and well-supported PHP framework then you could do a lot worse than choose Laravel. In fact you couldn’t really do a lot better. It’s lightweight enough that it doesn’t get in the way of your planning and development work. But it does still offer plenty of structure and handy built-in features.