> magic framework stuff that Laravel/Symphony provide
The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
This is one of the reasons I like PHP, in newer PHP versions it is an attribute but in older versions it is just a comment. Clever and backwards compatible.
It isn't backwards compatible (`#[foo` used to be legal PHP 7, but is illegal in PHP 8).
It may technically be forwards compatible syntactically (`#[foo]` will, as you say, just be ignored by PHP 7), but that's an anti-feature (assuming that the attribute isn't a no-op, it'll presumably break something else).
And a program can generally read its source code and make fancy adhoc interpretation, sure. That’s nowhere close to specified facilities that you are guarantied to be able to use with a fair amount of trust in the resulting outcome with the regular toolbox.
I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses
One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.
Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
> when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
debug_backtrace() has always been my friend in situations like this
What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct.
I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits.
This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described.
Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design.
Again: Trade off.
That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
It's like that with every framework: Laravel, Rails, Django, you name it.
If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier.
Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
"...Once you try to build something that does not fit the confines of the framework..."
Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all.
I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go.
I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money.
As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity.
This happens a lot more frequently than you think.
We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.