Loved this article, those were all great points that I have faced on my daily job at a PHP shop.
A breath of fresh air in amids of thousands of "ew, such a bad language" and "a fractal of bad design", the latter being incredibly outdated and still referenced from time to time.
I love PHP, it was my first language and it's one hell of a productive ecosystem to be in. Laravel is an excellent choice for rapid prototyping and Symfony is probably one of the best web frameworks for enterprise projects. Paired with coroutines extensions such as Swoole/OpenSwoole/Swow it puts one hell of a fight performance wise with more modern languages.
Also, I have been looking for GraphQL implementations for other server-side languages recently and I have yet to encounter a schema-first implementation that comes close to what the Lighthouse layer for Laravel can do.
Lighthouse is sophisticated and productive. I only use it in fully-authenticated contexts but because it is schema-first with good ORM bindings and excellent annotation support, I barely write any logic that isn't a mutation, an accessor or a permissions gate. The occasional top-level query resolver. Beyond that it is the graphql schema and the models.
And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else.
Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit.
But generally it has meant a flexible API interface and leads to nice low latency UIs.
Funny, my opinion of Apollo on the front end is that it's the bees knees (specifically vue-apollo using the composition API), but it's the PHP graphql backend that I'm stuck with (Symfony API Platform) that I really wish I could ditch in favor of something like Lighthouse.
And I _hate_ Eloquent, but I'm that jealous of all the goodies in Lighthouse's graphql dialect. You pretty much can't use directives at all in API Platform :(
I'd only seen fairly raw GraphQL from like 4-5 years ago, when you had to write your own auth, resolvers, deal with n+1 queries, etc. This is actually really nice and solves a lot of the issues I was thinking of.
Right. People keep telling me that code-first is better but there is no way all those complex APIs are easier to use than just spitting out some JSON from an endpoint.
Schema-first feels more manageable.
I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things.
(e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.)
It's built on the WebOnyx reference implementation, so there's some help out there.
But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations.
It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
Another nice thing about schema-first is that clients can start interacting with a mock server from day-0, and both sides can build out the implementation independently according to the spec. It really speeds things up on larger projects (IMHO).
Working on FrankenPHP, we get a lot of issues from the Laravel people (mostly in regards to octane + worker mode), and I've been getting into more and more Laravel to support these folks and understand what is going on in the SAPI. I've really started to understand the attraction lately. Previously, I worked at Automattic for quite a while and learned the WordPress side of PHP, then worked with Symfony in a corporate setting, so I've yet to get into Laravel in the commercial world, but I'm thinking I probably will for my next job.
Also: I have removed the little bit of snark in my reply above -- it shouldn't have been there and I apologise. Rough brain-day making me jumpy but there's no excuse!
Dude. We've all been there, no offense taken. I probably could have taken a few seconds to explain my experience instead of just assuming everyone else has had the same experience.
Huh? This article is talking about very similar issue to the fractal of bad design. Down to repeating specific ones like json_decode(null). Most of the fractal post still applies. The themes of surprises and consistency are strong in both.
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.
The thing that I think PHP developers hate most about the Fractal of Bad Design article is hearing it from full-stack JS developers. They really do not have the moral high ground.
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/~
As someone who writes PHP and JS professionally every day, I think they're leagues apart.* Sure, people love to look down on JS, but its fundamentals are much stronger than PHP's.
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:
> As someone who writes PHP and JS professionally every day, I think they're leagues apart.
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.
I actually think the opposite is the case. let is nice, but javascript has no typing whatsoever. The PHP type system isn't perfect (with a lack of generics being the biggest pain point), but in javascript you just have to annotate and pray (or use typescript and compile it back to javascript, hoping people interface with your code correctly). And PHP has a dedicated string concatenation operator, which has helped it avoid horrors like '2' + 2 = 22 that javascript has to offer. Javascript will just straight up let you add properties to any object on purpose or by accident, which is useful for polyfills but also fucking horrible for bug avoidance and an invitation for less restrained individuals to make true abominations.
All of those things I see as productivity issues, not language fundamentals. TypeScript solves types in JS for me the way Laravel solves superglobals in PHP.
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.
In php 8.3, there is a new json_validate function! Stuff changes, it just takes a bit of time. Luckily, the core maintainers have been putting out steady releases every year and old versions are being deprecated on a rolling 3 year cycle. It doesn't solve the historical problem, but hopefully it enforces better habits for the ecosystem moving forward.
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.
Just out of curiosity, when was the last time you worked with Symfony?
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.
Symfony is not great, but most people utterly misuse it so you end up with spaghetti and ground mud. That being said, Symfony is the most popular framework I know of that liberally uses goto statements.
I haven't worked very much with Symfony but I've never seen a goto. In fact, the last time I've seen a goto statement was maybe 15 years ago in a mIRC script.
Where are those goto statements? I'm asking out of curiosity to check them.
> These days it's very similar to Java's SpringBoot.
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.
It is actually documented, surely you must be confused?
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.
I think his complaint is that a lot of the Symfony docs don't simply say what things are/do, they instead inform via examples. Which means you have to parse the examples first to understand what's going on.
Yes, "documentation" implies a curated and complete reference, not a collection of code snippets that may or may not apply to your current problem and version of Symfony.
(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.".
Some of the points are outdated, but the soul of the article, that those stdlib inconsistencies and language quirks as you called it, lead to terrible design and a lot of surprising footguns, is still quite true. Laravel is a good framework and it is because it hides a lot of PHP from the user.
A breath of fresh air in amids of thousands of "ew, such a bad language" and "a fractal of bad design", the latter being incredibly outdated and still referenced from time to time.
I love PHP, it was my first language and it's one hell of a productive ecosystem to be in. Laravel is an excellent choice for rapid prototyping and Symfony is probably one of the best web frameworks for enterprise projects. Paired with coroutines extensions such as Swoole/OpenSwoole/Swow it puts one hell of a fight performance wise with more modern languages.