Having worked with PHP both as a hobby and professionally for more than 10 years I saw a lot of progress in community to use best practices. The language itself has evolved a lot. Some years ago we didn’t have composer or namespaces, we have come a long way.

Frameworks have always been available, but as time passed, they began to offer more comprehensive tooling and better practices, with popular options like Zend Framework, CakePHP, CodeIgniter, and Symfony. Over ten years ago, Laravel emerged, and with the release of version 4, it quickly became the most widely used PHP framework. I this post I want to explain why Laravel should be considered harmful for the PHP community. I did use Laravel with 20 devs working on the same project and that’s how I learned how harmful and toxic this framework can be.

Technically

• Singleton usage: The container has a singleton and unfortunately this singleton is used everywhere across the codebase. The Container interface is almost useless because event if we implements this contract, Laravel's container concret implementation will be used by the framework. (Related issue: https://github.com/laravel/ideas/issues/1467) (Occurrences of "Container::getInstance()": https://github.com/laravel/framework/search?q=Container%3A%3AgetInstance%28%29).

• Traits: Traits are used everywhere in Laravel. Trait should be use with caution. It’s easy to bloat classes because it’s still a vertical way to add code, similar to inheritance. You cannot remove a trait if you don’t own the code. In the majority of the cases, using dependency injection would be the right way, to have logic in a specific class.

• No dependency inversion: This is a pretty basic concept that should be understood by everybody. Injecting dependencies is extremely important to be able to decouple the code, to be able to test things, to make it easier to compose. Unfortunately the framework uses app() in many places which makes things act like a black box. It’s hard to test, it’s hard to mock. You need to open files from the framework to understand how it works, instead of using the contracts (inputs available). For more info https://phptherightway.com/#dependency_injection and https://en.wikipedia.org/wiki/Black_box.

• Models is a mixture of 2 concepts: In Laravel models are.. well, model but also infrastructure layer, because they implement the Active Record pattern (which breaks the Single Responsibility Principle). Models hold a state and are tight to the database. While this is “ok” for small apps, it makes it hard to unit test, hard to decouple and doing too many things. It’s also hard to test because it’s coupled to the database. Using the data-mapper (repository) pattern is better outside MVP/little applications.

• Facade pattern: Models/Service/Tools, almost everything uses the “facade” pattern. Not only the facade pattern has nothing to do with what is implemented in Laravel (see https://en.wikipedia.org/wiki/Facade_pattern, thanks Taylor for the confusion) but it’s also a terrible practice. It’s yet another part of something that we cannot mock with east, it creates a blackbox and pushes to not use dependency injection. Yes it’s possible to mock facade but it’s hacky and it’s not based on a contract. We can change the service and break everything, there is nothing that enforce us to follow anything. The only advantage facade have is to be able to use them like it was a singleton, but that’s exactly what we don’t want. It should never have been a thing, dependency injection is such an important concept.

• APIs are too flexible: the API of many objects is just too flexible. Many arguments accept string|array, there is many methods to do similar things which makes it hard to keep conventions without good tooling. For example when you have a request you can do $request->foo or $request->input(‘foo’) or $request->get(‘foo’) or $request->toArray()[‘foo’] and other ways from Symfony. What a mess. On top of that using $request->foo (or $request->input(‘foo’)) will work with request query OR request body. Like that when you have a public API you don’t know what clients will use, enjoy documenting it, enjoy edge-cases. Please use $request->request for body and $request->query for query, from the Symfony API.

• Too many god classes: If we take the request example again, it simply does way too much. It extends Symfony request, it implements 5 traits (!) and provides a lot of methods. We should use composition instead. Why does $request->user() gives you the user? The return type is mixed yet you can get a full user directly from the request? Why the hell there is the Mockable trait in the request, I don’t want to use it, I don’t want devs to use it? Why so many utils?

• No single class responsibility: it’s related to many points cited before but, how do you get a user? $request->user() or auth()->user() or Auth::user()? Yes all of those are hidden dependencies, the answer is: you should inject it! Inject Auth or bind the user to an argument somehow.

• No type hints: Why isn’t there more type hints? PHP came a long way, it’s now more “type safe” than ever, yet the most popular framework doesn’t want to use that. Not only it makes the code less safe, but I saw some devs arguing that it’s not needed because “if Laravel doesn’t do it, it’s not needed”.

• Magic methods: There is a LOT of magic methods everywhere. While I dislike that, some usage are “ok”. The problem is that it’s over-used and it makes some part of the code barely readable (for example https://github.com/laravel/framework/blob/5f304455e0eec1709301cec41cf2c36ced43a28d/src/Illuminate/Routing/RouteRegistrar.php#L267-L285).

• Components are tightly coupled: it’s hard to use a Laravel component outside Laravel because it requires many other packages and wiring. This is due to many bad practices mentioned before. The community did something to try to fix that (https://github.com/mattstauffer/Torch).

• Macroable mess: This trait is use to do monkey patching. Not only this is a terrible practice. But those traits cannot be removed from production. On top of that, the framework use them to add some features. For example validate in Request. By doing so we 1. Need a phpdoc comment to make it clear to the IDE that this method exists (@method array validate(array $rules, …$params)) but we also need to make sure that the “provider” was called to set this “macroable” logic (there https://github.com/laravel/framework/blob/5f304455e0eec1709301cec41cf2c36ced43a28d/src/Illuminate/Foundation/Providers/FoundationServiceProvider.php#L143-L153). How messy is that… it’s so hard to follow, it’s hard to refactor. Macroable is another thing that should not be used in production, if not ever. Why is it forced on us?

• Functions don’t have namespace: it’s available since PHP 5.6 but Laravel still don’t scope functions. Instead they check “if function exists” to register the function. I’m wondering why they namespace the classes. Functions, functions, functions: there is so many functions. Many functions use singleton behind the curtains. Again, this push devs to use them and to create black boxes. Again there is no dependency injection when using app(), view(), validator() or anything else. Just in the helpers.php from foundation there is 60 functions! Support has 22, Collection 7. All of them Polluting the global namespace for no reasons. Some logic are only in functions: Many functions are basically “aliases” but some contains too much logic, for example data_set() has 50 lines of logic! Why is it not in an object? We need to depend on this function in some places.

• Alias: Laravel ship many classe aliases, and again, what is the point? To avoid one line to import something? Why does the framework has this enabled by default? It’s a minor thing but it makes it harder to have tooling to enforce architectural choice and I don’t understand what it brings except confusion.

• It’s not SOLID: The more I work, the better I appreciate this acronym. At first it could sound overkill but it really does help a lot to understand the code, to be able to test things, to avoid god classes, to decouple logic. Having worked with both, I can tell that working in a codebase well designed improve the productivity a lot. It may not be obvious for small projects but as soon as the project grow it is extremely important.

• No strict typing: This one is less of a big deal because it can be use in business code anyway but Laravel never use declare(strict_types=1) which would improve type safety on their side.

• No usage of final: No classes are using the final keyword in the framework, even if devs are not supposed to extends something. This makes the code of devs using the framework more fragile because “internal” classes can potentially break things at any time. It’s not clear what it internal to the framework or not and there is no backward compatibility promise (unlike Symfony for example https://symfony.com/doc/current/contributing/code/bc.html). Using final would prevent inheritance misusage, push for composition over inheritance and make the contract between the framework and the devs more clear. I would argue that classes should either be abstract or final.

• Bad encapsulation: Many classes have protected fields. Why? To be able to extends of course. Instead we should have things private and use composition over inheritance. But because the architecture is not well designed in many places it was easier to have it that way. I saw some devs never using private because of that. “We don’t see it outside the class anyway, better to be flexible”.

• Over usage of strings: Strings are used in many placed to configure things. While some usage are fine, there is often a limitation about using strings and it creates more issues than it was intended to solve. For example in the validation, the middleware etc. On top of that it’s not possible for the IDE to understand. This point is a bit more subjective.

• "Dumpable" trait: a new trait was introduce to dump class, not only I don't see why this bring but it continues to bloat more classes. Simply do `dump($foo)`, this trait doesn't bring anything.

• There are many, many other things (code style doesn’t follow PSR-12, the foundation part is not a package in itself, “Application” is a terribly bloated god class, there would be much more to say about Eloquent, etc.).

Sect-like

The problem with Laravel is also that Taylor justifies bad practices and make it looks “cool”. Years of better practices in the PHP community are destroyed by someone not understanding some basic concepts like dependency injection and encapsulation.

Not only many tweets are extremely cringe (like this one https://twitter.com/taylorotwell/status/1647011864054775808) but they are provocative and don’t do any good to the community. Again, Facade is another patter from the gang of four, and no it’s NOT “fucking good code”. It’s you choice if you need to show off your orange car but this is all but productive to my eyes. I never saw any other core framework devs being so proud of itself. We should educate, write blog post, agree or not with arguments.

In another recent tweet he is saying “final is trash” (https://twitter.com/taylorotwell/status/1650160148906639363), it’s pretty incredible to me to not understand the value this keyword brings. In some language (defensive style) it’s even the default behavior and I think it should be that way. The problem is that Taylor doesn’t explain why he doesn’t like it, it’s simply “trash”.

I saw many young devs following what is he saying, thinking “final is trash”, “facade are great”, not understanding why injection should be the way to go. It divides us and make PHP looks backward in many aspects. Of course it would take more time for Taylor to deconstruct things, it's easier to say things are trash and "I just want good vibes" with a carefully selected emoji to look cool.

I could continue to write much more but I’ll stop there. I'll probably never hire again someone who just worked with Laravel. I just want to say: be careful with Laravel, the documentation and the framework do NOT use best practices. You should understand why SOLID exists, this website does a good job to explain many concept: https://phptherightway.com. Please don't follow Laravel and Taylor blindly, if this framework is "cool" it's because of flashy marketing and not code quality.

~~~

Edit: Thanks for you feedbacks. I'll add some questions to have a better discussion:

• In your eyes, should Laravel be considered harmful?

• In a perfect world, what would you expect from Laravel and/or Taylor?

Edit 2: Related post 8 years ago "Why experienced developers consider Laravel as a poorly designed framework?" (https://www.reddit.com/r/PHP/comments/3bmclk/why_experienced_developers_consider_laravel_as_a/)

Edit 3: I know it's a controversial topic in PHP's world but I would not expect so much anger from a part of the Laravel community. I'm sure it would have been much more constructive in other ecosystems. I tried to list points precisely, I tried to reply to many comments with calm and I'm attacked on twitter because "I'm jealous of Taylor", "That I don't know how to use a framework" and even that I should be "taken outside and punched a few times" (https://twitter.com/TheCelavi/status/1652314148284366850). Is this how mature we are? Why can't we talk about the subject instead? It's not about me, it's about this framework and some part of the community who will defend Laravel without even readings or understanding the points, it does feel like a cult sometimes. You don't have to agree with everything, but let's be constructive, let's care about others, let's build better things and learn from each other.

Edit 4: I actually appreciate the response from Taylor (https://twitter.com/taylorotwell/status/1652453534632415232), I wrote it before, I don't have anything against him personally and I don't think he is "dangerous" as a person. I just think it would be great to talk about the technical points I mentioned before. It feels that it's a fight of egos & communities instead of talking about the Framework's issues and the fact that Laravel community is so defensive, those are real issues IMO.

I find it sad that it's just jokes to discredit this post and that flaws are not taken seriously by Laravel.

Edit 5: Some people are accusing me to "spitting a bunch of design “rules”" and that I don't know shit. I didn't use my main account for obvious reasons but this is just easy to say. I tried to give precise points. Please tell me if you need more examples or more explanations, it's not hard to provide. Breaking down things takes a lot of time and energy. It's easier to troll and discredit, let's be mature instead.

Edit 6: *Sigh...* I saw many tweet saying that I needed to shit on Laravel because Taylor has a Lambo, how unrelated is that? Is this the only argument have left? I never say that you cannot build products that bring millions with Laravel, that's is absolutely not the point. But it proves once again that a part the community is really hermetic to criticisms.

I have been developing in Laravel and I loved it.

My work colleagues that have been developing for over 10 years (I have 2 years experience) say that Laravel is maybe fast to develop and easy to understand but its only because it is poorly designed. He is strongly Symfony orientated and as per his instructions for past couple of months I have been learning Symfony and I have just finished a deployment of my first website. I miss Laravel ways so much.

His arguments are as follows: -uses active record, which apparently is not testable, and extends Eloquent class, meaning you can't inherit and make higher abstraction level classes -uses global variables that will slow down application

He says "use Laravel and enjoy it", but when you will need to rewrite your code in one years time don't come to seek my help.

What are your thoughts on this?

Many thanks.

I see people get really emotional when it comes to discuss laravel. Can anyone provide valid reasons why laravel is or isn't a good framework.

P.S. I have solid OOP knowledge and attempted to build my own framework for fun xD.

Edit: Also can you compare laravel to symfony.