Thinking About Using Laravel?

Why you might want to think again...

Posted 5 months ago by Tom Maiaroto.

Right off the bat - I believe using any framework is better than not using one at all when developing web applications. However, that doesn't mean you can do no wrong if you're not careful.

I've worked with (and contributed to) many frameworks and open-source PHP projects over the years. I've given up on the "performance" concern that everyone else seems to be obsessed with. That does not define how "good" a framework is. Of course there can be bottlenecks that can be problematic, but may not necessarily be problematic for the project at hand.

For fun, I have profiled many frameworks to see if certain claims out there were warranted or not. What I now focus on when deciding if I like a framework is how well it solves for the important issues; development speed, code organization, maintenance, working in teams, etc.

All that out of the way, I wanted to touch base on this new framework called Laravel. I've been using it for about 5 months now. I've certainly given it a fair shake and I wanted to highlight my findings and opinions in the hope that it helps the framework improve. I think one day it can be something nice, but long story short - I'd pass on using it for now.

First off, I find Laravel's API to be very inconsistent and strangely organized. It doesn't seem well thought out. It could be that the intent was to start by making an ORM that solved one particular problem (which I personally don't find very "eloquent" at all) and the rest of the framework merely became an afterthought (hence why so many parts of Symfony2 are used). I'm not really sure, but the more you use Laravel the more you feel that it was just thrown together in a rush.

This feeling is well accented by the fact it changes versions very frequently with many breaking changes. Laravel is, without a doubt, maintenance hell.

Things I Consider Problematic with Laravel

  • It borrows so much from Symfony2 that there's practically no point in using Laravel. One might as well use Symfony2. If you like the strange Eloquent ORM, just bring that into Symfony2.
  • It has a 6 month release cycle yet likes to label itself as "stable." This is a contradiction in my mind especially given each version comes with a good list of breaking changes. Sometimes with horrible API changes (I've spotted several incompatible class constructors after a recent upgrade that forced me to adjust my code in a hacky way).
  • Most 3rd party packages end up not being maintained and no longer work because they were built for Laravel 3 or even 4 (and we're on 4.1). I imagine people who build packages specifically against the Laravel API end up giving up because it changes too frequently.
  • It does dependency injection wrong (it's not alone in this though). There's also no DI for your controllers or in the constructor of the base controller and in general you can just call whatever class you want (see: or for a good example of DI in PHP).
  • It doesn't properly namespace. So, as mentioned above, you can simply call whatever class you want from pretty much anywhere. You won't be using PHP's "use" statement so this leads to poor organization and potential naming conflicts.
  • Laravel's facades aren't actually facades (see While they aren't problematic in and of themselves, it's problematic to go down the path of misleading people (as Laravel does in so many ways already). It's also confusing.
  • Not very good with cross cutting concerns. Leads to a lot of DRY problems.
  • While routing is mostly borrowed from Symfony2, it's not the most flexible nor the quickest. (One should look at Lithium's routing or for a good example of routing done right). This leads to more routes needing to be defined which can be a bottleneck for an application.
  • Poor routing and poor response class lead to less than ideal tools for building RESTful API type applications. Some concerns can be solved with the use of Laravel's routing filters...But they are basically a hack for the poorly thought out routing.
  • It assumes too much and provides user login classes beyond what a framework should. This ends up getting in the way when you want to do something different with users/passwords and resetting of those credentials.
  • On the same assuming too much situation, it also assumes you'll want a "created_at" and "updated_at" field on your model records which you must know about and include in your table schema otherwise you'll run into errors. You can flag them off, but that's a bit annoying and what if you want to simply call the fields something else? "Convenience" features like this should be avoided in a framework because it is too assuming.
  • CLI commands are annoying to work with because they must be registered instead of automatically discovered (annoying - over configuration problem). You only get one command per PHP file which can lead to organization problems. There's an implied grouping of commands by command name (a class property) but not by class method. So when a user uses the CLI it looks organized, but when they look at the commands directory, it looks like chaos. Commands aren't namespaced either which is a sadly missed opportunity for organization.
  • Laravel has a slow bootstrap. One of the slowest I've ever seen. Just in case you're concerned about performance (it's not a huuuge issue for me personally).
  • No model validation (and suggested use of validation at the controller level from documentation) leads to poor design practice. Lots of repetition here. Maintance hell. Fortunately the, 3rd party, Ardent package helps with this. Laravel core should just adopt Ardent.
  • Simple relationship definition is done with methods which is stupid (again Ardent helps with this). Another example of being overly complex and forcing the developer to write more code which results in slower development.
  • No model schema to gatekeep and clean up invalid fields, so you get more SQL errors if you aren't careful. You end up writing more code to check for fields...and again, this leads to utter maintenance hell because instead of managing schema from one location, you have to hunt throughout your codebase each time you make a change. Laravel is already partly there with its guarded property and mass assignment stuff...I'm scratching my head on this fumble.
  • No built in ORM model updates? You can use the DB class to make any query you want (even more verbose and annoying) but there's no easy way to update without first having to run a find (creates an unnecessary select query).
  • SQL WHERE conditions can't be defined using an array with the ORM. So you end end chaining where()->where()->where() until you're frustrated. Also, when you do this, it becomes more difficult to pass some method you create a bunch of interchangeable query options. If the query accepted an array format, it would be far easier to manage query conditions that need to dynamically change without the need to write additional loops, switches, etc. It hinders development speed.
  • Limited ORM (without 3rd party add-ons). Where's the support for the newer and cooler databases?
  • It suppresses too many PHP errors by default and has a poor exception handler which makes it annoying for development (without some adjustments - it can be fixed, but it's annoying).
  • Debugging CLI command classes is a pain because of the error handling and reporting.
  • If a CLI command class has an empty getArguments() method; it will have an error, even though nothing was passed. It should be smart enough to work the same way as if it wasn't even defined. Or the approach to getting arguments needs to be changed and optimized.
  • It has poor documentation beyond the basics (if it weren't for and - i'd have spent a lot more time figuring out things). Though many frameworks suffer from poor documentation. Even my most favorite one.
  • The "workbench" is a stupid idea and leads to package managment issues (giving you a another composer project within the main application already under composer). In fact, it's now suggested to not use it.
  • Environment configuration is extra verbose and requires a bunch of files and folders for minor adjustments - and it's redundant. The main config gets loaded always and is overwritten by an environment specific one. So it doesn't so much "switch" as it "overrides" which is less than optimal and can create some confusion.
  • Far too many things are registered globally, creating a much larger memory footprint. It doesn't take as much advantage of lazy loading as it could.
  • Templating engine is blatant wheel reinvention without any benefit or need, one might as well use mustache. The blade syntax was borrowed from mustache anyway.
  • No automatic/suggest/implied structure for template pathing which makes for maintenance issues and team collaboration issues. Without some sort of organization convention, it's up to the developer and this leads to issues in teams. I feel a famework should at least have a good starting point for people...Which can be broken if need be.
  • Form helpers, like most view template helpers, are a joke.
  • Overly complex directory structure. There's a "bootstrap" and "config" etc. These all contain configurations that can do the same kind of things.
  • ...And if you needed any more... When a framework is so tightly integrated with another one, stuff like this can happen:

Long list I know...And some points are preferential things. I honestly hope that Laravel can address some of these because it could be a good Symfony2 alternative or "spin" on Syfmony2 (kinda like Silex - only Laravel wouldn't be a mircoframework of course).

So to be fair, there are some good and even clever things about Laravel. However, the list of negatives is far too great for me. Even if Laravel solves certain things better than other frameworks, it's nothing significant enough to warrant the use of Laravel.

It's just not worthwhile in my opinion. It would need to adress most of the issues above before it began to be considerable. Even if you were to replace the poorly designed parts with your favorite packages, you'd then be questioning why you were even using Laravel because you would really be using so little of it.

In general, I feel that it fails as a framework becauase it doesn't do its job in guiding you to writing cleaner, more organized and maintainble code.

I would honestly recommend anyone interested in Laravel to simply skip the headaches and proceed directly to Symfony2. It is far more mature and well thought out. Laravel is merely a crippled Symfony2. Edit: As a flame enducing comment correctly pointed out, tihs last bit was a bit too pushy. I don't want to push people toward a specific framework. I think the experience of using many frameworks is good in fact (it was for me). However, I really did want to suggest to people that they might want to look into something else. There are, in fact, many good alternative frameworks out there that don't suffer from (as many of) the issues outlined above. I can't stress enough how important it is to have organized and maintainable code. Companies these days must hire more PHP developers because their code is so disorganized that it actually takes more workers to maintain it. It actually doesn't have to be like this. Laravel leads us down that road (in its current form - note I said that I'd like to see it mature and become a good Symfony2 child framework). That's all I'm going to say about the matter.

Filed under
comments powered by Disqus

Search for Posts

Popular Labels

social media virality score general internet web development reviews and opinions php web tools hosting lithium web design

Recent Posts