Back in the day we used Symfony at work. I have a vague feeling that some of my coworkers looked down on Laravel. Less dependency injection, more weird magic.
> I have a vague feeling that some of my coworkers looked down on Laravel. Less dependency injection, more weird magic.
Well, you can rest easy knowing it probably wasn't just a vague feeling, because I'm pretty sure every moderately experienced programmer who has tried both and went with Symfony feels that way.
Laravel was clearly written from the ground up with one goal above all else: to make it was easy as possible for beginners to write babby's first website as fast as humanly possible. Every other essential aspect of such a framework (maintainability, modularity, code clarity, ease of debugging complex issues, etc) was thrown to the wayside in favor of that one main goal, which is why there's so much "magic" everywhere. You're expected to just blindly trust the magic and never look behind the curtain. Unfortunately, beginner programmers that have no intention of ever evolving past their beginner phase are a huge audience nowadays, so you end up with many people who have never had to write or maintain a complex codebase hailing Laravel as the next coming of Christ.
This is all heavily reflected in this article: the author picks one of the most extremely simple use cases to implement, a 99% static page with a single dynamic variable that doesn't even seem to use a database. And despite the code being extremely simple, he still has to ask AI to write 90% of it for him because he isn't interested in learning how anything works, he isn't interested in expanding it or maintaining it in the future, he just wants to pump out the minimum viable product as fast as possible.
Laravel follows dubious practices: god objects (like a parent class which has hundreds of functions), static functions etc. The kind of practices our product is actively moving away from (originally based on Symfony 1 which had all the architectural issues Laravel has now), because it didn't scale beyond CRUD (makes it easy to write hard to support spaghetti code etc.). So it feels like a step backward... Especially when you learn they base it on top of Symfony which is already great and nicely designed.
Count me as one of those disgusted by weird magic people. Unfortunately for us, the majority seem to love it. The more coding resembles throwing spaghetti at the wall and seeing what sticks, the happier they are. "What do you mean this could have been 10 lines and no frameworks; that can't possibly be complex enough [for some ETL thingy]."
Well, you can rest easy knowing it probably wasn't just a vague feeling, because I'm pretty sure every moderately experienced programmer who has tried both and went with Symfony feels that way.
Laravel was clearly written from the ground up with one goal above all else: to make it was easy as possible for beginners to write babby's first website as fast as humanly possible. Every other essential aspect of such a framework (maintainability, modularity, code clarity, ease of debugging complex issues, etc) was thrown to the wayside in favor of that one main goal, which is why there's so much "magic" everywhere. You're expected to just blindly trust the magic and never look behind the curtain. Unfortunately, beginner programmers that have no intention of ever evolving past their beginner phase are a huge audience nowadays, so you end up with many people who have never had to write or maintain a complex codebase hailing Laravel as the next coming of Christ.
This is all heavily reflected in this article: the author picks one of the most extremely simple use cases to implement, a 99% static page with a single dynamic variable that doesn't even seem to use a database. And despite the code being extremely simple, he still has to ask AI to write 90% of it for him because he isn't interested in learning how anything works, he isn't interested in expanding it or maintaining it in the future, he just wants to pump out the minimum viable product as fast as possible.