[boredpudding]

Not OP. While I didn't quite PHP. I just don't work with Laravel.

A lot of good points are written down here: https://old.reddit.com/r/PHP/comments/131t2k1/laravel_consid...

In short, it just doesn't use good programming principles. It's not just easy to write code with bad principles, it's everywhere in the tutorials.

There's of course Laravel apps out there that do have good programming principles. It's very much possible to write good code with Laravel. It's just less common.

[ahofmann]

I think the reddit post missed the point multiple times. Laravel does not use the best principles everywhere, yes. Taylor Otwell is a (very) strange person, yes. But "Laravel should be considered harmful for the PHP community" is just wrong.

Laravel was the first framework, that "just worked" and had everything, you need to make your first steps in a web application. Nowadays, people write PHP components that are usable in Laravel and that means a lot of code out there is compatible to a lot of other code. That alone did a lot to the PHP community. 2010 or so, the PHP landscape was much more scattered and things didn't look good.

Since then a lot happened and Laravel carries old stuff with it, and I'm very happy about that! I'd hate to be forced to do big refactoring work on every update of the framework. As strange as some decisions in Laravel are, they try new things, and they also try to stay compatible to the old stuff. Between Laravel 5.5 (released 2017) and 10 there were not much breaking changes. For a framework, this is a big plus.

[ckdot2]

"Laravel was the first framework, that 'just worked' and had everything" - well, there was Symfony before. And CakePHP, and Yii (which was also considered as quite easy to learn), and much more. Laravel may did a few things "better", especially for junior devs, but it's not the first.

[mgkimsal]

Laravel didn't have all this on day one, but having docs and supported configurations for something like queue processing. IIRC, there were community plugins for CakePHP for queue processing, but it wasn't something the core framework embraced and supported out of the box. I don't think Laravel had this until their v4.

My experiences with cake and zend back ... 10-12+ years ago... things 'worked' mostly, but there was often a lot of "you can do it any way you want", and often minimal examples for the cases I was trying to achieve. Testing... as much as it was there, my experiences trying to get decent testing never seemed to work very well; Laravel's testing experience felt better out of the box. Testing traits like 'useDatabaseTransaction' to rollback the db after each test seemed both useful and novel - I don't remember seeing things like that in Cake (at least not early on - haven't checked recently).

FWIW, I use Laravel a lot these days, but wasn't terribly 'trusting' of it early on. Started seeing it in what I guess were its 3.x days; then saw 4.x - big changes, and what seemed like a moderate amount of BC breakage, then again from 4-5. Around 5.x, it seemed to adopt a bit more of an incremental approach to changes, and I started using it more day to day in the 5 series.

[ahofmann]

I tried CakePHP at the time and it was awful, like many other PHP frameworks of the time (remember joomla?). Frameworks were either "what the framework provides is easy, but don't dare to do anything that the framework is not made for" or "just do what you want, we provide almost no help, just figure it out by yourself". And all of them were slooooooow. It wasn't possible to answer a web request in under 50 milliseconds with any PHP framework in 2008.

Laravel was awful when everyone else were awful. But around Laravel 5.5 (and PHP 7) it was complete enough, documented enough and fast enough, that you could just start building stuff with it without having to think about it. Is Laravel the best Framework out there? Not at all! But is also not considered harmful, far from it.

[JodieBenitez]

I thought Sensio labs and PHP-FIG made lots of efforts to have compatible code...

[mgkimsal]

They did, and the outcome of that is a couple generations tools/libraries that have more standard compatibility 'by default'. That has enabled another generation of frameworks (Laravel probably the largest of those) that can take a 'mix and match' approach, using 'best of breed' bits from the community as well as their own ideas and philosophies.

[solraph]

Also not OP, but the linked reddit post sums up one of the major reasons I had to get out of PHP several years ago. Everything is/was moving to Laravel in PHP land. I got tired of dealing with highly coupled, non-unit testable code that seemed to go out of it's way to ignore SOLID principles.

God help us if it this project becomes the normal way of writing http go servers applications. Maybe at that point it's time to become an embedded rust programmer or a monk.

[lakomen]

People like you, not meant personally, are the reason I abandoned PHP. Too much dogma. Too much nonsensical paradigms without considering pragma.

Who gives a shit about SOLID or OO.

I used to love PHP for its simplicity. That was before zealots of your type flooded the ecosystem.

You wanted to apply what they taught you in uni, which was Java, to PHP. PHP was fine before. I earned good money with it and had fun doing so. Then 2010 the next generation of clueless devs enters the scene, polluting it with their nonsense.

Very much what's happening in Go right now with the cloud microservices fetish.

Can't you booksmart idiots STFU for once and let people do the pragmatic and sensible approach?

Fucking Hipsters

[solraph]

> Who gives a shit about SOLID or OO.

The people who care about and are tasked with maintaining a large long running code base.

> You wanted to apply what they taught you in uni, which was Java, to PHP.

Nope, that came after my time.

> Can't you booksmart idiots STFU for once and let people do the pragmatic and sensible approach? I earned good money with it and had fun doing so. Then 2010 the next generation of clueless devs enters the scene, polluting it with their nonsense.

Those OO & OOP principles are the pragmatic and sensible approach learned after cleaning up after "hipster" web "artisans". If we're going to throw around claims without knowing anything about the other person; you sound like the kind of dev who writes some code that works on the happy path, but is completely unmaintainable and non-extensible.

(But I know nothing about you, so I really have NFI, just like you have NFI about me and what I do)

[sshine]

When I studied computer science, I promised myself to never touch PHP again.

But PHP has more to give than just as a birthing ground for teenage programmers.

When I many years later accepted a PHP job as a senior developer, PHP provided a consistent experience of "bad practice everywhere", a fractal of cringe I couldn't ironically reproduce. Working with this for a year taught me a lot about how to deal with critical legacy software beyond repair and being responsible with what you've got.

I think there is no better way to get your hands consistently dirty than with PHP.

Coincidence: I do embedded Rust, and my wife is a buddhist monk. ;-)

[cardanome]

Many of my programming jobs in PHP had me working with people that were super anal about "good coding practices". Especially the Symfony guys seem to try to be the new ultra-corporate Java. So I don't think it a issue with the language but more that you didn't find your people. (Personally, I actual like working with legacy crap. It's easy money and reminds me of the past when things were simpler.)

I feel most of the PHP community is pretty mature these days. More pragmatic than Rust, sure but that is a good point in my book. Though I am glad you found your enlightenment.

[lakomen]

Symfony was the worst. Holy shit dude. I still have to deal with a legacy Symfony project, which needs to be rewritten because of their... I don't even know what to call it.

That stof guy was one of the worst. Inconsistencies, incompatibility. But the dogma was strong.

Indeed they wanted to be the Java of PHP. And so inefficient. Imagine duplicating all variables of a request context for dogmas sake. So you can later do Request->getVar() from their own copy. It shows a basic not understanding of the language.

[sshine]

> I don't think it a issue with the language but more that you didn't find your people

I can be more specific: I'm identifying problems with the language ecosystem.

I deliberately didn't shit on the people involved; I'll definitely ride the #not-all-php-programmers (I've met some great ones), but it takes a broken mind to accept a toolchain this historically fallible as something with which you'd want to recreate the Java ecosystem. ;-)

Have you tried Java?

It's definitely a better Java than PHP!

[ckdot2]

"bad practise everywhere" - you could say that for C++, Python and many more programming languages, too. If we're honest - most of the code out there is poorly written. PHP - nowadays - doesn't prevent developers in following good practises.

[dpcx]

What would you like to do with PHP/Laravel that isn't unit testable? Laravel is, from my experience, written in a way that specifically makes testing of most things very easy.

[antifa]

Yeah, I'd like to know, too. I've done laravel + TDD for almost a decade and I can't think of anything you can't test or mock. Emails, Queues, Guzzle requests, AWS SDK, events, grammers, sessions, etc.. You name it, I've probably done extreme TDD to it.

[esprehn]

It seems like they thought a lot about making sure everything could be mocked and tested: https://www.goravel.dev/digging-deeper/mock.html