I agree that the language evolved since then, but the main categories are still not solved in the language. Nice frameworks just hide those well.
I agree that the language evolved since then, but the main categories are still not solved in the language. Nice frameworks just hide those well.
PHP has improved since in a way that is rarely considered when reposting it, but JS has some deep language horrors of its own still, and many novel JS horrors like NPM have emerged largely since the Fractal article was published.
As the King sang, so eloquently: o/~ clean up your own backyard o/~
PHP is no longer a terrible language- recent editions have made leaps and bounds on language features, and the ecosystem around Symfony is great. But on a weekly or monthly basis I run into something that makes me want to head-desk.
JS's recent(ish) language improvements like `let` and ESM have been much more fundamentally significant than PHP's IMO, where we're still stuck with bad scoping and Java-brained class autoloading.
*Not leagues apart in terms of productivity. I can certainly get a lot done with PHP. I mean leagues apart at their foundation, the basic concepts at work in the language. Most of that can be ignored until it rears up to harass you. Here's a great example of something similar to an issue that bit me last month:
Adding properties to an object is fine IMO. Arbitrary properties and prototypes are, to me, a much cleaner system than PHP's somewhat confused mix of array, object and class. The lower you go in JS the more unity of concepts there is, whereas the lower you go in PHP the more hacks you discover.
All of the above said, I would prefer a string concatenation operator to overloading +. JS template literals mostly solve that for me in practise. And what I really actually want is an equivalent of Haskell's <> or mconcat, which concatenates anything monoidal - strings, lists, etc.
As someone who’s written a lot of php and JavaScript, I think the same thing but in the opposite way. JavaScript just can’t compare when it comes to designing a complex OO system.
Rather, point out the fact that Symfony is a framework that relies entirely on all sorts of magic behavior, and at the same time it is entirely undocumented.
One of the most horrible programming experiences I've ever experienced.
PHP is a nice language, but the community is insane.
The framework has changed massively after the earliest versions (1~3). These days it's very similar to Java's SpringBoot. After scaffolding all you get is a thin layer with the HTTP abstraction, configuration support, reflection-based Dependency Injection and a testing framework (PHPUnit).
Since the framework is component-based you pull dependencies as you need them. I find the documentation really good and honestly I don't see much magic in it, it's an event-based web framework. Laravel and it's facades on the other hand is very magical.
Where are those goto statements? I'm asking out of curiosity to check them.
https://github.com/search?q=repo%3Asymfony%2Fsymfony+goto&ty...
I highly recommend learning how to use it.
That's not a positive. Spring Boot is impossible to use for anything except an unmaintainable abomination, since the whole thing runs on undocumented magic.
You have the docs with extensive examples, you have a free book, and the whole framework is typed and all configuration options and the individual components referenced: https://symfony.com/doc/current/index.html
And if you use PhpStorm with the Symfony plugin almost everything gets intellisense.
Also, random code snippets that may or may not work is not documentation, much less is it a reference.
(No, random posts oт Stackoverflow and generative AI responses aren't a replacement for documentation either.)
The blog author makes solid points that I agree. Meanwhile AFOBD just make fun of stdlib inconsistencies and of language quirks, most of which were fixed throughout the years.
AFOBD is so incredibly outdated that this paragraph is still there: "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.".