69

Laravel is the worst framework ever.

Everything has to be made convenient and easy. That sounds amazing, because developers want to save time, worry less about boilerplate code, right? No more constructors, no more dependency injection, fuck all the tedious OOP shit... RIGHT?

It does one thing well: Make PHP syntax uniform and concise through easily integrated libraries such as Collection and Carbon. But those are actually not really part of the framework... just commonly integrated and associated with Laravel.

The framework itself is completely derailed: You can define code in a callback in the routes file. You can define a controller in the routes file. You can define middleware as a parameter to the route, as a fluent method to the route, you can stack them up in a service provider. Validators can be made in controllers, Request objects, service providers, etc. You can send mail inline, through Mailable objects, through Notification objects, etc.

Everything is macroable, injectable, and definable in a million different places. Ultimate freedom!

Guess what happens when you give 50 developers of various seniority a swiss army knife?

One hammers in a screw with a nail file, the other clips the head from the screw using scissors, and you end up with an unworkable mess and blunt tools.

And don't get me started about Eloquent, the Active Record ORM. It's cute for the simple blog/article/author/comment queries, but starts choking when you want more selective and performant queries or more complex aggregates, and provides such an opaque apple-esque interface which lets people think everything is OK, when in reality it's forcing the SQL server to slowly commit suicide.

Comments
  • 7
    I use Laravel every day, i love it... but you are absolutely right...
    Laravel 4.x was awesome, the changes to 5.0 impressive; unfortunately they didn't know when to stop adding "features" to the framework. From release 5.1 things were changing to the worst.
    I object with your rant when you say that it's the worst php framework; it can still be awesome used in the correct way (using common code conventions).
  • 13
    That swiss army knife analogy rules :D
  • 4
    @HomeAlone I think the problem is that:

    1. Laravel uses conventions which conflict with common code conventions (especially cohesion/coupling wise).

    2. There are very little Laravel specific conventions. It doesn't say: Put your validators in this directory, make a repository for every model.

    There's a lot of vaguely defined patterns, too many situations where devs think: "should I put this in the model, in the controller, or should I make a viewcomposer, a presenter, make a transformer?". There are no clear conventions for those things.

    Laravel also stretches the capabilities of PHP through heavy use of "magic" get and call methods, trying to emulate features from other languages.

    Maybe it's not all Laravel's fault, the community has created a lot of popularized half-assed libraries, PSR-2 is a small set of vague rules, and PHP is too weak.

    I think Laravel could learn something from the language Go: Sometimes it's good to be strict and offer only one way of doing things.
  • 3
    Yii 2 anyone? :)

    Laravel feels really hacky IMO. I used only Laravel 4 though so I can't be sure.
  • 2
    @bittersweet again: i agree 100%
    When the magic works, everything seems so cool: "wow, a built-in paginator! I just have to add a blade directive in my view"
    But when you have to customize the paginator, you'll end up forcing the orm builder to write a hopelessy complex query.

    Sometimes the lack of coding guidelines (or the excess of "freedom") drives away from the mvc pattern itself...

    I hope for a change in next versions of laravel
  • 1
    @arekxv no, but it's one of my good intentions for 2018 ;-)
  • 4
    @SyntaxError365 Laravel is fine for a personal project, because you can easily set up and enforce your own rules for consistency.

    In my case I'm dealing with 50+ developers in 8 teams, and 34 million lines of code.

    I honestly don't know what to pick if I was going from scratch — Not PHP. For our use case possibly Scala for the high availability web backend, with some Go microservices (we already use those) to make it easier on junior devs.

    (oh you deleted your comment?)
  • 2
    OOP is tedious? ok then, enough internet... time to sleep.
  • 1
    I did lol sorry! I didn't want to know the answer and just wanted to cry in my corner regarding going full steam ahead...into a brick wall.....@bittersweet
  • 3
    I set up my own convention rules in my team. Happy with laravel so far.
  • 2
    @MrCSharp OOP being too tedious (coming from JS, Python and Ruby) is Laravel's raison d'être I think. Having worked with it for a few years now, it kind of feels like Taylor was punching Symfony while crying: "Why can't you be more like Rails, more fun and sexy! Who cares about performance, you need to be easy!" But easy, fun and sexy has resulted in too many STDs.
  • 2
    @SyntaxError365 @CurseMeSlowly

    Yeah like I said, it works quite well up to a certain point, no need to worry if your product has clearly defined functionality and can be managed by a small team. If you expect to grow beyond a certain complexity, I'd start offloading things to microservices with clearly documented APIs of their own.
  • 3
    I wanted to try laravel. I installed it, then i looked at those big number of files and folders, then i gave up. I just want simple route controller not database shit.
  • 3
    Nice to see so many becoming aware of the downsides of Laravel. Maybe the mass hysteria is coming to an end.
    Maybe now and we can start talking about good solid programming principles to solve problems instead of constantly seeking canned solutions that bloat and complicate our projects.
  • 0
    You're right, but I really like working with it! I work with Django python and that's just amazing. Maybe you'll like it? It's more easy to work with then Laravel and the documentation is really good.

    It depends on the project which framework I use. They both do the job but for bigger projects I guess I like Django more.
  • 1
    Maybe you need to reconsider team structure and split into smaller teams to work on projects rather than 50 Devs on one project. I think you will have similar problems with many frameworks, but maybe Laravel isn't for your use case. Try bringing in code reviews to better enforce standards / guidelines.
  • 1
    @chrisrhymes Yeah we have PR reviews, multiple scrum teams, guidelines, PHPUnit tests, dusk/selenium/karma tests, code styling tests, pipelines which enforce product owner functionality reviews, the list goes on.

    The weak point is still that you can write a guidelines -- but in a large team everyone from devs to reviewers needs to know about these guidelines. You can whip them, but if neither language nor framework helps to write correct code... it's seemingly futile when you reach a high deployment velocity.

    PHP is not always the devil people make it out to be, but it does suffer from scaling and safety issues.

    I think our biggest mistake is developing a central product that's too monolithic -- 34M lines PHP should probably be 20% of that size, with the other 80% distributed into other products, reusable modules/packages/microservices which are developed in isolation, and can communicate with the central product.
  • 1
    I love laravel but I have been working on a project that uses smarty. Go google it
  • 1
    @octogato ik but either way it's bad
  • 1
    @octogato no lol it's cancer
  • 2
    I must disagree. I work on a dozen Laravel projects and I love the framework.

    The problems you're describing lie with the language itself, not with the framework itself.

    Second problem is with developers, I have one laravel instance I need to take a dump everytime I open the code. No other laravel project I work on with other seniors has these problems.

    You can take a strict framework or something as blunt as Codeigniter, if a dev doesn't know how to use it, they'll find ways to write the code in a way that will make you question their intelligence.
  • 2
    @orijin Fair points.

    My biggest issue with the framework (or should I say Eloquent) is the opaqueness, where $user->credit could be a normal property, an accessor method on a single user model instance, a scope on all users, or a cached collection obtained earlier from a database query. Sure, you should prevent this implicitness as a developer by giving good names and sticking to logical patterns, but it loosens up PHP even further instead of helping devs with better habits.

    I see people who are relatively experienced developers struggle with active record orm patterns, because while it's easy and magical it also hides the true mechanics so well that it leads to performance problems.
  • 1
    @bittersweet can't argue there. I don't use eloquent much tho, we have our own API, needles to say, which has its' own performance issues.
  • 1
    Eh, Laravel has worked for me thus far.

    I think Laravel does certainly give you a whole arsenal to do one thing 1000 ways; that i can agree with.

    Perhaps to declare quite audibly that you can and should be able to do whatever you want, even if it's stupid. How else does a new dev learn, right?

    Facades are magic, middleware makes me cautious, and Eloquent can be expensive, but there is always a right tool for the job.

    Complex queries should be left to more low-level raw query building with typical paramaterized queries, and anything less intensive or complex is much more appropriate for the Eloquent methods to handle.

    In a team of 50+ devs, most likely there will be juniors, or simply differings of opinion; each can lead to people thinking the 'other' devs are imbeciles, or the framework too forgiving.

    In any case, any good, passionate dev would likely not exhibit most of these idiosyncrasies.

    Overall, love it for what it is, beautiful core code, great for the experienced
  • 2
    You did not mention that Laravel puts all of your sacre environment variables on a HTTP page...
    In the entire world there isn't any framework that does this but Laravel.
    Whoops there was an error and there are all of your environment variables, sent over HTTP or HTTPS... the least secured protocol in web development.

    One would try explaining them that this is utterly f*cked up, but they keep covering their asses with the statement "you must not enable debug mode on a public server, and on a private server this is no problem"... Kinda shows the level of education the developers of the Laravel framework have had.

    You never print passwords in logfiles, nor in a HTTP response... Tell'em, they won't listen
    https://github.com/laravel/...

    Environment variables on a debug page are of no interest to a developer, who single-handedly entered them wilst installing the SQL-server and entering the same credentials in the .env file. Why do I NEED to see them on a debug page?
  • 0
    when u can work with python ruby Js Elixir Scala Clojure ...
    why u choose php and laravel ?
  • 1
    @morteza

    Try recruiting 50 Scala devs...
  • 0
    @bittersweet yes thats too hard for find scala developers
    but u can start with django or rails
    laravel is piece of shit and i cant understand why people instead of rails or django start to using php-laravel ! also laravel has performance issues !!
  • 0
    @morteza Rails and Django have the exact same issues.
  • 0
    @bittersweet big frameworks are complex and have very details.
    u can use microframeworks like flask , slim ....
    i myself prefer to use frameworks like flask ,finatra ...
    easy to custom
    easy to learn
    ....
  • 1
    Try to debug code written by another dev. You just slowly drown config files, controllers and callbacks. After you are infected with Middleware-Mania you die a slow painful death thinking where the damn middleware you are looking for is hidden. Is it in the middleswares folder? Or does it come with a composer dependency and is buried in vendor/ ?

    You will not find out, you died of old age (and Middleware-Mania)
  • 0
    The spectrum of PHP developers--their education, their experience, and their commitment to learning software engineering--is vast and varied. Those looking for employment as PHP developers get hit over the head with job descriptions that include Laravel.

    Laravel is a system. Some people are followers and submissive. They will accept Laravel and justify it because they get a benefit from doing so. Even if Laravel goes far beyond what is necessary to set the ground work for an MVCish application, people still praise it.

    Given the opportunity to simply apply sound OOP and software engineering principles, they balk and do what they think they are expected to do (conform and survive).

    Thus, using Laravel amounts to cognitive dissonance. This is true of many frameworks, but especially Laravel. You might not want, or need, to use a framework, but you have to due to some outside force. Oh, then it rubs of on people.

    Laravel is a system, and businesses like order.
  • 0
    I'd rather say: don't use a framework that puts environment variables in a debug page...
  • 1
    @Pieterjan Dude, why are you being toxic on GitHub about an issue that really doesn't matter (you don't show debug pages publicly anyway), and keep spreading your anger here in an old topic?

    I get it, you have an autistic pet peeve about laravel which shouldn't be an issue if you read the docs 😉
  • 0
    I just registered in this website to note my frustrations using Laravel and Voyager.

    The first day I was impressed how fast and easy I was able to do the simplest things, like ACL's, CRUDs, model relationships, etc..

    But when I had to do little bit more complex things and when I dug dipper into Voyager, the rate of WTFs increased rapidly.

    Looks like we have a Wordpress monster in a new shape coming through Laravel. There is no stopping now, the monster is out and getting traction
  • 1
    @NakiroKuro you don't have to use Voyager if you don't want to. It's a quick and dirty tool to jump start things at initial stage of a laravel development.
  • 1
    There are many haters on the internet, it's pretty easy to say, "some thing is shit", and this type of post add's nothing but misunderstood about tools like Laravel, and lead people to wrong assumptions based on relative pessoal impressions.
    What is hard to understand is that, almost everything has a point of view and not every truth is the definitive truth...
    We live in a multi dimensional universe, where things like time, speed and weight, and not only your current x and y axys matters...
    In future, one could say "Django is shit", and you'l be in the same position as a Laravel dev is now reading your post...
    Try to share more respect and compassion and you will start to grow your skills as a person not only as a dev.
  • 1
    "...when in reality it's forcing the SQL server to slowly commit suicide."

    $relationships = [...]; // count($relationship) = 100

    Model::with($relationships)->get(); // Produces 300 SQL queries

    Gotta love eager loading every single nested polymorphic many to many relationship with ordered uuids as pks.
  • 0
    @Pieterjan

    I know you posted almost a year ago but... just put APP_DEBUG=false in your .env file and the errors won't show your environment variables. It's by design.
  • 0
    @nitnip

    Even in a private development environment (say at your company) it is considered amaturistic to print credentials in a webpage.

    And APP_DEBUG does not prevent the Whoops page from being returned from the server (It's been proven time and time again). The only thing that does is not to install the filp/whoops package by running `composer install --no-dev` as described by the docs.
  • 0
    @Pieterjan

    I agree showing the whole .env file is not needed most of the time (you can open it in your own editor). The only time it has ever helped me was when the configuration was cached and the changes I made in my environment variables wasn't working correctly.

    I didn't know it was considered amateuristic though. I've only had the (mis)fortune of working for companies that do not care much for QA (They prefer to put out broken shit fast to make the clients wait. "It's fine, we can fix it later!" mentality.) and my managers never had good technical background.
  • 0
    Laravel is Shit. Eloquent is Shit. Blade is Shit. I'm 100% accord with you. Why do you need to use a diferent function if you compare a field and a number instead two field? (Where vs wherecolumn by example).

    Ah! And the documentation is shit too.
  • 1
    I unapologetically love Laravel.
    But I work on these sorts of projects alone. And if they ever want another developer to work with me, they'll be learning to use it exactly the same way I do, or else they can go and sit in the corner and play with their Yii shit
Add Comment