Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn 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).
That swiss army knife analogy rules :D
@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.
arekxv10404yYii 2 anyone? :)
Laravel feels really hacky IMO. I used only Laravel 4 though so I can't be sure.
@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
@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?)
OOP is tedious? ok then, enough internet... time to sleep.
cursee176334yI set up my own convention rules in my team. Happy with laravel so far.
@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.
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.
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.
niko1264yNice 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.
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 love laravel but I have been working on a project that uses smarty. Go google it
@octogato ik but either way it's bad
@octogato no lol it's cancer
orijin20584yI 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.
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
Pieterjan33yYou 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
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?
when u can work with python ruby Js Elixir Scala Clojure ...
why u choose php and laravel ?
DBX126823yTry 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)
delturge03yThe 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.
Pieterjan33yI'd rather say: don't use a framework that puts environment variables in a debug page...
@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 😉
NakiroKuro03yI 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
tnatanael13yThere 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.
"...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.
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.
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.
LaraShit02yLaravel 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.
ojt-rant569303dI 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