Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
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). -
@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. -
@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 -
@arekxv no, but it's one of my good intentions for 2018 ;-)
-
@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?) -
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
-
@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.
-
@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. -
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. -
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.
-
@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. -
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. -
@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. -
@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.
-
-
@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 !! -
@morteza Rails and Django have the exact same issues.
-
@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
.... -
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) -
@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 😉 -
@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.
-
@siliconrockstar no that was Livewire for Laravel. which I also unapologetically love, and hope it becomes integrated in to Laravel by default.
Add a little AlpineJS to that and you've got yourself a lovely Tall Stack. -
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.
undefined
fuck laravel