Hacker News new | ask | show | jobs
by ahofmann 1076 days ago
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.

2 comments

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

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.

I thought Sensio labs and PHP-FIG made lots of efforts to have compatible code...
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.