Hacker News new | past | comments | ask | show | jobs | submit login

> [...] its defenders should focus on actually showing what modern PHP code looks like.

Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master).

Laravel has a Java-like problem of too many indirections, and has a really complex application model that breaks a lot of things. For that you gain an end of 00's quality templating system and ORM.

I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.

Just out of curiosity. What type of comparable work are you doing and what languages/frameworks are you using? How do they compare?

I've created reasonably complex projects on Django (with late 00's capabilities), I've done things in Flask, Asp.Net, Java (with very out of date components), very simple things on Rails, and also used some non-OOP frameworks like snap, I've also used some newer templating systems. I have never created anything in Laravel, but I have done some maintenance.

Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).

The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.

Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.

If laravel is the best we have were fucked.

Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.

Symfony is better at handling backward compatibility and managing deprecation.

Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.

Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.

Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.

Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?

I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability.

Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.

One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.

That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).

Yes, they are supposed to.

The problem is that it gets taken to extremes when it's done at the framework level.

The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.

Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.

If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.

IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.

The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.

Within modules usual namespacing and new constructors were used liberally.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact