[dubcanada]

I find it funny the author choose Symfony as a framework to "shudder" about. Considering the base of Laravel is Symfony.

The rest of the article seems to be more about AI code editing and MUX video players then PHP.

So I am not really sure what I am supposed to take from this post.

[ainiriand]

Laravel is really not great for some use cases, while with Symfony you have the flexibility of doing the things the way you want.

For example, in Laravel you have the dependencies sprinkled all around the app and with Eloquent you kind of need to use active-record.

I am not a big fan of Laravel but I think it is a great tool to build websites, not sure about data heavy backends.

[drivingmenuts]

Since I no longer work on big projects, I actually prefer Codeigniter. It's just simpler and yes, it doesn't do nearly as much as Laravel and I'm OK with that.

[steve_adams_86]

Ha, this reminds me of a time I was proposing our team use Symfony rather than Laravel for a new project. It was such a battle.

Eventually I wrote up a document (I must have spent 20 hours on that thing) showing the pros and cons according to our needs and what each options offered. The gist of it was that Laravel was a nice wrapper over Symfony components at the time (though it did offer more as well, too - it just wasn't the more we needed), and since we were kind of like power users (data heavy backend with tens of thousands of users, rapidly growing), we should go direct to the source and use the Symfony components without any abstraction.

I mean, we shouldn't have been using PHP at all at the time, but what can you do.

Literally no one arguing for Laravel knew it was based around the Symfony components. Once the CTO saw that and heard me out, we didn't actually end up reviewing the Laravel option at all. I was so relieved.

Those were weird times. I'm not sure how much Laravel has changed since then. At the time it was kind of like an easy way to build simple stuff fast, but it didn't strike me as a great tool for our use case. We needed to make the most performant php-based booking system possible, and some basic benchmarking showed that Laravel introduced some incredible performance penalties that didn't make any sense for us.

Sometimes I miss that product. It had massive potential. I still stumble across it while booking stuff. The UI has barely changed. I suspect they haven't made many changes or made much progress since I left 7 years ago. I really wanted to build it into something better.

Long story short: Laravel wasn't the right choice for that kind of application, no one who wanted to use Laravel had any idea about its architecture but argued with me about it for weeks, haha. Write detailed documents to support your case, it works wonders.

[alecsm]

Laravel hasn't changed much. I mean, it did, PHP also changed a lot in the last years but the whole idea behind the framework is the same. Full of features, easy to set up, many tools built around Laravel to deploy your app, to build your own SaaS, etc but it's highly opinionated, you have to do it their way.

Symfony on the other hand takes more work but it's more flexible. One of internal apps is made with Symfony and after working on it for a couple years, if I had to set up the whole thing again I wouldn't know how.

[tasuki]

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.

[bakugo]

> 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.

[kgeist]

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.

[TOGoS]

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]."