There’s been an article circulating in the PHP community titled “Why You Should Not Use Laravel“. Having over 15 years of professional experience with PHP and many frameworks such as the author, I also have plenty of valid input for this.
I think the title is thought-provoking but misguided and potentially disingenuous. The author points out that “Laravel is Not PHP” and “Don’t Use an ORM” to support its title.
Laravel is PHP
First, I disagree that Laravel isn’t PHP. I would argue that Laravel very much takes advantage of many of PHP’s core features, including some from the SPL.
If you’re curious enough, you’ll find that these features can be leveraged to your advantage. I also disagree that Laravel is “syntactic sugar”. If he’s trying to say that the code written in Laravel doesn’t look like the PHP written decades ago, I’ll give him that.
Modern PHP Practices
Laravel definitely embraces what I would describe as “modern PHP practices”.
Especially because it uses a lot of features from the SPL, Composer is at the core of it, and even introduces multiple paradigms such as some functional programming.
Laravel is open-minded in the sense that it looks at making coding more simple and more stable, but also allowing developers the flexibility to adapt the framework for different use cases.
Syntactic Sugar? Meh.
The only true “syntactic sugar” in Laravel is the templating language, which really isn’t unique to Laravel. Smarty, a very popular PHP templating engine before Laravel existed, has been around for over 20 years–20 years!
And with similar “syntactic sugar”. Templating engines aren’t even unique to the PHP ecosystem. There’s practically a templating engine for every major language, Node, ASP.NET, Ruby on Rails, and others.
Perhaps by what he means that “Laravel does TOO much hand-holding” is that you can write less code to do the same thing. My experience as a senior developer is that writing more code leads to more bugs.
Many other thought leaders outside of PHP have said the same.
Perhaps he’s talking about the automatic dependency injection. If that’s the case, have you tried writing dependency injection manually?
It’s extremely verbose, error-prone, and overall not a pleasant experience. Laravel does add some abstraction over that, but if you’re truly a seasoned programmer you’ll be able to learn the internals and even learn from those patterns.
Laravel does have opinionated conventions, but not so written in concrete that you can’t change those conventions to adapt to large projects. Want to write an application with more of a Domain-Driven Design approach perfect for a large application? Yes, that’s absolutely possible with Laravel thanks to Providers.
ORM allergies are not unique to Laravel
Another point that I somewhat agree with, but I don’t agree how it somehow supports avoiding Laravel is that he says “Don’t use an ORM”.
Now, in most things software development, those that are absolute about something usually are dogmatic. ORMs have plenty of issues if not used appropriately and of course, if you’re seasoned enough you should already know that “it depends”.
If you use an ORM so that you don’t have to worry about database design and manually writing SQL statements, then yes, you’ll absolutely run into issues such as the famous N + 1 problem, which the author alludes to. All of those can be remedied though.
Eloquent, but not always relevant
Personally, I think Eloquent is very well made.
The fact that many enterprise PHP projects have chosen Doctrine as the goto for the database access layer is nothing but a phenomenon of following the bandwagon and nothing to do with PHP itself, nor Laravel.
These decisions often start from lead roles choosing the direction or inheriting it from large projects. And again decisions like this happen in other ecosystems and are not unique to PHP, but I digress.
Should you not use Laravel because it has an ORM? At least that’s how it’s portrayed in that article. Did you know that you don’t have to use Eloquent to access your database layer? Nothing is stopping you from using Laravel’s Query Builder or any other query builder (especially since Composer is built-in) or PDO, or anything else.
Should you not use Laravel? In the end, “it depends”, but not because it hand-holds you so much that you don’t actually use PHP or because it has an ORM.