Sure. PHP, especially post 5.4 has matured a lot and offers as many niceties as your favorite blub language. It has its warts, but at this point, nothing worse than what Javascript has for example.
That said, while you can write beautiful code in PHP, IMHO, Laravel is not that.
It full of "string typing", over-applied and mis-applied Design Patterns, and poorly thought abstractions.
It just saddens me that Laravel is considered well designed and advanced codebase, or, worse, a standard of how PHP should be coded.
While it's not as bad as the Wordpress spaghetti, it is mostly Java EE (circa 2004) in PHP, sans the strong typing assurances (and, fortunately, sans the gobs of XML too).
On the other hand, Laravel works and has a strong community going for it, which, as in the case of Wordpress, makes all the difference in the world.
A lot of the over engineering in Laravel comes from Symphony, which in turn inspires how Laravel is built. And with the Proxy pattern in use everywhere, it inspires high coupling in your code in a way that doesn't quite look like coupling but is nonetheless.
I would argue that Symfony is well engineered, not over engineered. The fact that Laravel is already at version 5 demonstrates just how poorly engineered it was in the first place.
That's an odd argument. Is Rails poorly designed because it's had 4 versions, or Django because it's had 8? Seems much more to do with the pace of the development than the architectural quality, to me.
EDIT: It depends on what the versioning represents.
I don't think there have been as many breaking changes in Rails vs Laravel, and Rails at v4 has been over ... 9-10 years? Laravel is < 6 years old, with, from what it seems to be, rather significant philosophical changes between major versions. Doesn't mean it's bad, but perhaps closer to using gentoo vs centos.
When I tried SF2 I found it to be a terrible, Java-like, pile of abstractions. This might work for some people, but if you prefer thinking about business logic (as opposed to "where do I extend this IoC dependency container so that it can find my ControllerFactory), it's not for you. It left me bitter.
Yii is supposed to be nicer, I heard from colleagues, but I left PHP programming the moment I saw the opportunity so I can't vouch for that.
Extending the IoC container?? A ControllerFactory?? You never do anything like that in Symfony. The thing I appreciate most about Symfony2 is how it enforces good design patterns.
One might argue that the SOLID principles applied in Symphony and inherited by Laravel are in fact anti-patterns which only serve to add massive cognitive overhead. They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
There's even less reason for a scripting language with a GIL to be saddled with this level of complexity, than there is for Java.
Much of the complexity in Symfony comes from its "dependency injection" component (a misnomer, really) and the inclusion of annotation magic in the standard framework distribution.
These days, I'd rather use the basic components (e.g. Symfony's HttpFoundation library) with something like league/container (formerly orno/di) and a simple routing library like nikic/FastRoute.
> They've wrecked countless Java projects over the years and are now going to do PHP the same favor.
Oooh do enlighten. I made an argument when Symfony2 first came out that PHP isn't Java, and now I've been brainwashed to think the Symfony community is right.
Very refreshing to here an alternative point of view :)
Can you elaborate on "the SOLID principles [...] are in fact anti-patterns"? I don't see this point of view exposed often, can you point me to some resources in this regard?
Take a look at phabricator's source code, which was originally developed in house at facebook but is currently open sourced. It's not using any of the big MVC frameworks, but it's very well written (despite using PHP 5.2 compatible only syntax) and I think a good example of a well designed PHP codebase.
Though the Symfony2 community hasn't been open to criticism and suggestions for improvement.
And eventually, when they've taken some of the original criticisms on-board (at v2.6) [0], they themselves get shot down by parts of the community for spoiling the architecture.
