Using Laravel: first impressions of a PHP framework

laravel logoOur 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

The rest

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.

10 responses to “Using Laravel: first impressions of a PHP framework

  1. Great to see that appreciation of Laravel is beginning to spread!

    My experience has been very similar – I’m beginning to find php programming fun again…

    I’m setting out on quite a complex little project, and initially rejected Laravel as being attractive but too lightweight.

    So I spent some time wrestling with one of the “big frameworks” before realising it was getting in the way as much as it was helping. Back to Laravel, and everything has slotted into place within days.

    The more I dig into the guts of Laravel, the more I’m coming to respect the design. It seems to deliver 90% of the power of the big frameworks, but with 20% of the learning curve and effort. And because it’s standards compliant, you can simply drop in libraries from Symfony2, Zend2 etc if you need specific functionality.

    In particular I’m finding Laravel extremely flexible, so it’s possible to get things done the right way, rather than do back-flips to fit in with the framework.

    Taylor, the lead developer, has managed to hit a sweet spot of power and flexibility without complexity that I haven’t experienced with other frameworks. So despite its youth I feel that Laravel is a serious option for commercial work, especially if you are trying to do something a little out of the ordinary.

    1. Good to hear you’re finding Laravel fun too! I think often people feel that a complex problem needs a complex solution, but I’m not sure that’s true. I’ve certainly been caught out before by a simple problem becoming rapidly very complex just because of the way a framework organises itself. One small workaround leads to another, which leads to another bigger one, which…

      Being so new to Laravel I hadn’t realised you could drop in symfony and zend libraries so easily. That sounds very cool. I also haven’t really had much chance to try out the many bundles out there. Certainly at first glance several seemed very useful.

      1. Because the docs are relatively young, there’s quite a lot of power there that’s not immediately apparent.

        For example, if you check out the start.php file, you’ll find a number of points where you can swap in your own drivers for functionality such as class loading or language translation. Or in the paths.php file, you can change the way you organise your directories. Or by editing an alias you can extend a core class without breaking any code that consumes it (though so far, I’ve not found the need to extend the core). All very simple, and all very useful.

        My project involves a series of storefronts on different domains that are sharing many models and libraries, but with different controllers, content and views. And each storefront will have a number of portals for customers and staff, each requiring their own sessions, users etc. And I need full G11n for the customer facing elements.

        I tried to get this set up in Symphony2 but found that I was fighting the framework. Then I tried it in Yii, and found that I could only do it at the cost of breaking the generators which are Yii’s main selling point, because the generators are highly opinionated about the structure of your project.

        With Laravel, all this has fallen into place cleanly and easily. It doesn’t have G11n as yet, but with great help from the community I’ve got something written in less time that it would have taken to figure out the G11n features in one of the corporate frameworks – and it will fit my requirements 100%.

        So now I’m thinking that perhaps the big frameworks try to do too much – there seems to be a tipping point of complexity beyond which the whole thing becomes counter-productive.

        One corporate UK user has abandoned Symfony recently because they found it was too expensive to get new staff up to speed – but I’m not really sure what Symfony can do that you couldn’t get done more easily in Laravel. Perhaps it’s stronger for unit testing with its elegant IoC, but boy, you pay a price in terms of learning curve and cognitive overhead.

        It’s the same with ORMs – Doctrine is orders of magnitude more complex than Eloquent, but does it really deliver much more in terms of functionality?

        Laravel, on the other hand, seems to operate on the 80/20 principle, with just the 20% of functionality you need for 80% of your requirements. This makes it very much simpler, so it’s easier to understand and easier to customise. And when you need something that’s not built in, it’s easy to drop in a library or run up a quick library or bundle. And as you say, there are some smart people producing useful community bundles.

        Personally, I’m finding the Laravel approach a much better balance than wresting with a Zend or a Symfony. And it’s inspiring me to cut the sweetest code I’ve ever produced!

        1. Sounds like you’ve got quite a project there.

          I think you’re right about the 80/20 principle. I also think everything that’s designed or engineered in some way tends to go from simple to monstrous if not kept in check. You see it all the time.
          By the way I remember back in 2008 one of the symfony lead developers – Francois Zaninotto – left the project in exasperation because…
          “Symfony used to be simple, well documented, and powerful; today it’s just powerful. Long forgotten are the days where symfony’s motto was ‘Professional Tools for Lazy Folks'”.

          One of the key things a framework should provide is maintainability. ie. you’re not just doing random code in a way no one else will ever fathom. So it’s interesting to hear you say that a corporate user dropped symfony because it was becoming too expensive to maintain in terms of training people up. I guess that’s technical debt with a tangible financial cost!

  2. ” I also think everything that’s designed or engineered in some way tends to go from simple to monstrous if not kept in check. You see it all the time.”

    I think Laravel is pretty safe from this for the time being – just try to get a new feature into the core and you’ll find you have to make a very strong case!

    The idea seems to be to keep the core minimalist, and use the powerful bundle system to build an ecosystem of more specialised functionality.

    And the core code itself is pretty lean too – just compare Blade to Twig or Eloquent to Doctrine. In general the classes are short and readable. But although they are so much simpler, they seem to provide pretty much everything you need to get the job done quickly and elegantly, which is a sign of thoughtful design.

  3. This is nice text, and in some parts very funny (PHP guy, but last 12 months in RoR world ;). I am mostly interested in Laravel to build sites with possibilities to create custom content types (different view types, front-end content submission forms with different fields permissions, search filtering/options, tags etc.).
    I would like to see some project which was made with Laravel – can’t find any link, or showcase?
    Thank you, and best regards!

  4. Great post! Am also a developer at a university (Aberdeen) and have been investigating Laravel, as think it’s simplicity and flexibility could really work well here.

    Loving the out-of-the-box non-bloated but with sensible defaults state, but the ability to extend it easily yourself, drop in other packages etc.

    Thrown myself in at the deep end with developing a package (I need to extend the Schema and Eloquent classes to add in some extra functionality), but found it surprisingly straightforward to get going thanks to the wealth of documentation around, such as the official docs and the Code Happy book by Dayle Rees you mentioned above.

    I also found this blog Culttt where Philip Brown is constantly posting Laravel tutorials / info (amongst other things):

    Some of it’s introductory; others go into the advanced features (he recently built on an invite-only sign-up procedure).

    Many are related to him building up a site “Cribbb” using Laravel, and the code’s on GitHub too:

    Hope it helps anyway and keep up the good work!

Leave a Reply

Your email address will not be published.