This hits home for me. I started web development in PHP, went up and down the ladder a lot, but still continue to do PHP (Mostly Laravel these days). However, I am fascinated by the web in general and all the abstractions that make it stand up. More specifically, things like REST, HTTP, sessions, and all the web APIs that you consider for granted on the browser. Even things like CORS.
The nice thing about PHP is that it lets you play with these abstractions _even when you are starting out_. For eg, a redirect in ruby/sinatra would be `redirect https://google.com`, but stock PHP would want you to use the header("Location: https://google.com"); variant[0]. PHP doesn't abstract out the web, but lets you build on top of it. Its close enough to C so you know what is happening and how things are working (or atleast its easier to figure out), and still dynamic enough to get shit done.
There are problems with PHP's design, sure. But these are getting fewer and fewer with things like PHP7/Composer and the entire ecosystem still evolving. And believe it or not: there are problems with _every programming language_. Just pick the right tool for the job, will you.
[0]: I know comparing sinatra to PHP isn't ideal, but I am yet to see anyone code in pure CGI in Ruby.
Your observation on abstraction is interesting. I've always considered PHP to be quite the opposite.
e.g. Going from PHP to NodeJS, NodeJS is a lot more direct and less abstracted (handling the request directly, reading the request data incrementally and handling reader state, setting headers and then explicitly writing to the buffer, handling connection state, etc.) - note I do mean NodeJS here, not something like Express
another e.g. PSR-7 I find is, counterintuitively, actually much less abstracted than raw PHP built-ins as it goes out if it's way to map the interfaces to the stack as intended, rather than completely arbitrary weird abstractions. Like the retrieval of query parameters being entirely separate and unrelated to retrieval of the body payload, whereas PHP tends to sort of conflate these things in $_GET/$_POST/$_REQUEST and then doesn't really have obvious intuitive handling of non-x-form-url-encoded payloads. And don't get me started on query string array handling.
I do completely agree with the article though, and I still use PHP a lot. Voluntarily.
But I just found your specific observation surprising.
Agreed, nodejs lets you build servers from the ground up using streams. However, I am yet to see anyone build their first node project without something like Express and just use http.createServer.
The PHP abstractions are not always clear as you rightly point out (REQUEST = GET+POST+COOKIE...), but they are vastly different "magic" that you see in the Ruby land, for eg where you would rarely be ever thinking about cookies at all.
> stock PHP would want you to use the header("Location: https://google.com"); variant
Which is actually a broken abstraction, because in most PHP SAPIs that doesn't actually spit out a header line directly. Instead, it's parsed into its components, and PHP additionally sets the HTTP status code to a redirection one.
The 2 things that create the most beef about PHP are simply:
1. Type Safety (string? int? boolean?)
2. The Runtime Engine (apache? nginx? linux? windows? what file system?)
The flexible nature of these two concepts, leaves any given PHP script resting on shifting sands of uncertainty, which is really the only thing that leaves people feeling inadequate. The willingness to compromise, and accept a runtime where it's hard to debug, permits programmers to put themselves in situations where they'll have a hard time providing a conclusive answer in succinct terms, to non-technical folks disinterested in obscure details beyond the scope of one's external field or daily interests.
It's not because of impostor syndrome, or any sort of psychological underdog complex. It's simply the awareness that there are gaps in what's often expected to be a hermetic seal. And knowing about that, would gnaw at the edges of just about anybody's confidence at a subliminal level.
Every programming language has differences across platforms and servers, and the dynamic ones all have the type safety aspects. Those two arguments cannot be the reason because then javascript, python or ruby devs would be susceptible to the same.
The nice thing about PHP is that it lets you play with these abstractions _even when you are starting out_. For eg, a redirect in ruby/sinatra would be `redirect https://google.com`, but stock PHP would want you to use the header("Location: https://google.com"); variant[0]. PHP doesn't abstract out the web, but lets you build on top of it. Its close enough to C so you know what is happening and how things are working (or atleast its easier to figure out), and still dynamic enough to get shit done.
There are problems with PHP's design, sure. But these are getting fewer and fewer with things like PHP7/Composer and the entire ecosystem still evolving. And believe it or not: there are problems with _every programming language_. Just pick the right tool for the job, will you.
[0]: I know comparing sinatra to PHP isn't ideal, but I am yet to see anyone code in pure CGI in Ruby.