Why You Should Not Use Laravel

I’ve been a developer for over 20 years and used numerous PHP frameworks, including Laravel, Cake, Zend 1 & 2, CodeIgniter, Yii, and a home brewed one I wrote a while back.

Experience gives you a perspective you don’t get just using one framework over and over. As programmers, we are creatures of habit. We use what we know and if we’ve been using whatever language or framework for the past 5 years, well, that’s our go-to tool of choice. It’s familiar, like an old friend we know and know well.

But just because we’re familiar and comfortable with a language or framework doesn’t mean that it’s the best suited for the kind of projects we’re building.

I come from an enterprise background, projects that included hundreds of developers all working on various pieces of massive interactive applications. The really cool thing about working with such a large and diverse group of people is that you learn things, how to do this and that, not just more efficiently but more importantly, autonomously and extensibly.

I’m not saying Laravel is a bad framework for many different kinds of projects, but for very experienced developers, Laravel isn’t our go-to choice.

Why? Let’s explore a few reasons …

Laravel is not PHP.

I’ve read articles from younger programmers extolling the virtues of Laravel and how easy it is to use. One piece I read was someone saying they didn’t need to even learn PHP and SQL because Laravel takes care of that for you!

I actually sympathized with this sentiment because in my younger days I had the exact same thoughts. I loved working with an ORM because (I thought) I wouldn’t have to learn SQL. It’s a common misnomer.

The point is Laravel does TOO much hand-holding. At least for more seasoned programmers.

I am a graphic designer as well. Laravel prides itself as the framework for “artisans”. The impression is that Laravel is the framework for people who don’t really know how to code and don’t want to learn. I get it.

However, at some point all of us “artisans” are going to need to grow up to become real programmers. Laravel is not PHP, per se, it uses an “expressive” syntax or what has been coined as “syntactic sugar” to hide things from you that it thinks all of us “artisans” don’t need to worry about.

And that’s fine. Until we need to worry about them.

At some point, Laravel is going to drop the ball and you are going to need to get your hands dirty with real code, real dependency injection, real factories, real SQL, etc.

And all of this “expressive” syntax comes with a hidden cost you don’t see at the moment—Laravel is an extremely opinionated framework.

What Does Opinionated Mean?

Frameworks like Laravel, CakePHP, and others have very specific ways in which you must do things. And as long as your use case isn’t coloring outside the lines of what the builders of Laravel have imagined, you’re fine.

But it’s when your “use case” becomes the Laravel “edge case” where things begin to get interesting and suddenly you’re told to use some very odd looking code that drills you down into the guts of Laravel to expose what’s really going on under the hood.

Suddenly you’re saddled with code you’re unfamiliar with. Does it work? Probably. Do you know what you just did and why? Probably not.

And therein lies the issue.

From an enterprise perspective Laravel does too much. If you’re building a new SaaS platform, don’t use an opinionated framework as your prototype. Your prototype will become the product later on and it will become too expensive to just rip it out and rewrite it in Zend or Yii, two very UN-opinionated frameworks.

Don’t Use an ORM.

Just teach yourself SQL. Honestly, it’s not that hard to become proficient at writing good queries. An ORM makes you lazy and at the end of the day you are going to need to write SQL anyway.

I’ve used ORM’s in the enterprise and I hated it. Doctrine is the worst. Configuration is easy for simple projects, but when you get complicated with complex relationships via nested entities and recursion, hydration, you will want to pull your hair out.

I’ve had to write entire classes dedicated to doing nothing more than configuring Doctrine’s DQL (Doctrine Query Language) for what should have been simple SQL joins and pagination. It’s not simple when you’re using an ORM.

Also, ORM’s are expensive. A single Doctrine query for nested entities can run into literally dozens of queries to your database under the hood. Even for the simplest of entities we were seeing 6 to 8 queries to the DB for what should have been 1 to 2 at the most.

As PHP programmers we like to dump objects to the screen to see what’s in them. You can forget about doing that with an ORM. With recursion, dumping an object to the screen will consume all of PHP’s available memory and you’ll just get an error instead.

True, Eloquent is not Doctrine, but in the enterprise world, Doctrine is the go-to ORM, not Eloquent.

A good compromise is an Active Record pattern that models your table data but doesn’t get in the way of your code or try to manage your table relationships.

Conclusion

This isn’t intended to be a Laravel hit piece. Laravel is great for small to medium sized projects, internal business tools, or where you need to prototype something quickly.

But keep in mind that you’re using a very opinionated framework that makes you do things its way, and not necessarily the best way for your use case. Laravel will teach you some bad habits. It will also keep you from learning how more advanced PHP programmers do things under the hood.

Finally, if you are going to be building a project that has the potential to grow into something really freaking huge, using Laravel is a mistake; one that will cost your company huge dollars later on as really seasoned programmers join your team and start ignoring Laravel because it’s in the way.