4) Serverless as "CGI but it's trendy, [with vendor lock-in and a more complex deployment process]"
What vendor lock-in? Most of the code is just vanilla JS. There might be a different deployment procedure if you're using Cloudflare vs Lambda vs Vercel vs Serverless Framework, but those are typically still simpler than having to set up an SFTP connection or git repo in a remote folder. With a framework like Next, a serverless function is just another file in the API folder, managed in the same repo as the rest of your app. Even without a framework, you can edit and deploy a serverless function in a Cloudflare Sandbox with a few clicks and no special tooling. If you later want to move that to another serverless host (what an ironic term), you can copy and paste the code and modify maybe 10-15% of it to get it running again. And the industry is trying to standardize that part of it too.
And I think this directly relates to #1: It's not so much that serverless is high availability (which is nice), but more than they are well... server-less. Meaning maintenance-less for the end user. You don't have to manage a whole LAMP stack just to transform one object shape into another. If you already have a working app setup, yes, you can just add another script into your cgi-bin folder. But you can do the same in any JS framework's API folder.
5) Framework bloat
I feel like what this author really doesn't like is heavy frameworks. That's fine, they're not for everyone. But in either the PHP or JS world, frameworks are optional.
I guarantee you Drupal is heavier and more bloated than any popular JS framework (it's also a lot more powerful). Just like the PHP world has everything from Drupal to Wordpress to Symfony to Laravel, JS has Next, Remix, Astro, Svelte, Vue, etc. HTMX has Alpine. Ruby has Rails. Etc.
On the contrary, you can certainly write a few paragraphs of HTML as a string and render it in any of those frameworks, either as a template literal (PHP heredoc) or using JSX-like syntax.
That's not really what the frameworks try to solve. They are there for addressing certain business needs. In the case of the heaviest framework of them all, Next, it goes back to #3 and #4, about optimally separating work between the server, cache, and client. If your app is simple enough that you don't need that complexity, then either don't use that framework, use its older "pages" mode, or use another framework or none at all. If you don't need deterministic component rendering based on state, don't use React. If you don't need clientside state, don't use Javascript at all.
Similarly, you can write a dead-simple PHP page with a few server-side includes and heredocs, or maintain a labyrinthine enterprise Drupal installation for a few blog posts and marketing pages (not recommended... no, really, don't do that to yourself... ask me how I know).
In either case, it's again a question of "what do I want or need to maintain it". Choosing the right level of power vs simplicity, or abstraction vs transparency perhaps, is an architectural question about your app and business needs, not the language or ecosystem underneath it.
6) Vendor lock-in
You can host PHP anywhere. You can also host JS anywhere these days. In fact I'd argue there are more high-quality,low-cost JS hosts now than there ever were similar PHP hosts. Shared PHP hosts were a nightmare, because PHP was not easy to containerize for shared tenancy. JS hosting is cheap in comparison.
Most of the frameworks in either world are open-source. Not many are not-for-profit (Drupal is, but Laravel Forge/Forge and Vercel/Next have similar business models of open-source frameworks coupled with for-profit hosting).
In either case, though, it's really your application logic that's valuable (and even then, questionably so, since it'll likely end up completely rewritten in a few years anyway).
Ultimately we're all at the mercy of the browser developers. Google singlehandedly made shared hosting very difficult for everyone with the introduction by forcing HTTPS a few years back. It singlehandedly made the heavy JS frontend possible with its performant Javascript engine. WASM is still recent. WebGPU is on the horizon. New technologies will give rise to new practices, and new frameworks will soon feel old.
But JS is here to stay, because it's the only language that can natively interact with the DOM clientside. If your core business logic is written in almost-vanilla JS (or even JSX, by now), portability between JS frameworks isn't as hard as porting between different languages (like PHP to JS, or PHP to Ruby). Using it for both the client and server and in between just means fewer languages to keep track of, a shared typing system, etc. In that sense there's probably less vendor lock-in with JS than there is with PHP, which fewer and fewer companies and hosts support over time. PHP is overwhelmingly just Wordpress these days, which itself has moved to more dynamic React-based elements too (like in the Gutenberg editor).
I think the problem with the JS ecosystem is actually the opposite: not lock-in, but too many choices. Between the start and end of this post, probably five new frameworks were released =/ It's keeping up that's hard, not portability. You can copy and paste most of the same code and modify it slightly to make it work in another framework, but there is rarely any obvious gain from doing so. For a while there Next seemed like it was on track to becoming the standard JS framework, but then the app router confused a lot of people and now simpler alternatives are popping up again. For that much, at least, I can agree with the article: everything old is new again.
I couldn't agree with the article on almost any point.
One additional point: You can get "mildly dynamic" websites by using services. I have a completely static web site that's 100% on a CDN and that I've written zero lines of code for...but it has a full dynamic comment section due to Disqus integration. My "how many people have visited my page" is handled by Google Analytics. Other similar embedded services can provide many of the most common "mildly dynamic features".
I'm using Astro on a newer project, which allows you to static-generate pages however you like, but also allow you to run just one component as JavaScript, you can, without the inherent danger of running code on a server every time someone hits your web site. For full heavy-dynamic pages, you can render on the server as well. It's a nice compromise IMO.
That and I never want to use PHP again. Especially Drupal. I liked Drupal at first, but I never want to see it again.
> What vendor lock-in? Most of the code is just vanilla JS.
That runs in a specific environment with vendor-specific IAM configurations, vendor-specific DNS configurations, vendor-specific network configurations, vendor-specific service integrations, vendor-specific runtimes and restrictions, vendor-specific...
That sounds like an AWS thing? There's a lot of frameworks that can deploy straight to Vercel, Cloudflare Pages, Netlify, etc. without all that.
And if you really want to manage all that, it would apply to both PHP sites and JS and anything else. That's really more of a discussion of fully vs partially managed cloud solutions, not PHP or JS or any framework in particular.
> There's a lot of frameworks that can deploy straight to Vercel, Cloudflare Pages, Netlify, etc. without all that.
All of them need all that. And those frameworks are for a reason: they sweep a lot of these things under a rug, and after a certain complexity you will have a vendor lock-in. Just because you will end up depending on certain policies that other vendors don't provide. Or on certain services that other vendors don't provide. Or guarantees that other vendors don't provide. Or pricing that... Or...
4) Serverless as "CGI but it's trendy, [with vendor lock-in and a more complex deployment process]"
What vendor lock-in? Most of the code is just vanilla JS. There might be a different deployment procedure if you're using Cloudflare vs Lambda vs Vercel vs Serverless Framework, but those are typically still simpler than having to set up an SFTP connection or git repo in a remote folder. With a framework like Next, a serverless function is just another file in the API folder, managed in the same repo as the rest of your app. Even without a framework, you can edit and deploy a serverless function in a Cloudflare Sandbox with a few clicks and no special tooling. If you later want to move that to another serverless host (what an ironic term), you can copy and paste the code and modify maybe 10-15% of it to get it running again. And the industry is trying to standardize that part of it too.
And I think this directly relates to #1: It's not so much that serverless is high availability (which is nice), but more than they are well... server-less. Meaning maintenance-less for the end user. You don't have to manage a whole LAMP stack just to transform one object shape into another. If you already have a working app setup, yes, you can just add another script into your cgi-bin folder. But you can do the same in any JS framework's API folder.
5) Framework bloat
I feel like what this author really doesn't like is heavy frameworks. That's fine, they're not for everyone. But in either the PHP or JS world, frameworks are optional.
I guarantee you Drupal is heavier and more bloated than any popular JS framework (it's also a lot more powerful). Just like the PHP world has everything from Drupal to Wordpress to Symfony to Laravel, JS has Next, Remix, Astro, Svelte, Vue, etc. HTMX has Alpine. Ruby has Rails. Etc.
On the contrary, you can certainly write a few paragraphs of HTML as a string and render it in any of those frameworks, either as a template literal (PHP heredoc) or using JSX-like syntax.
That's not really what the frameworks try to solve. They are there for addressing certain business needs. In the case of the heaviest framework of them all, Next, it goes back to #3 and #4, about optimally separating work between the server, cache, and client. If your app is simple enough that you don't need that complexity, then either don't use that framework, use its older "pages" mode, or use another framework or none at all. If you don't need deterministic component rendering based on state, don't use React. If you don't need clientside state, don't use Javascript at all.
Similarly, you can write a dead-simple PHP page with a few server-side includes and heredocs, or maintain a labyrinthine enterprise Drupal installation for a few blog posts and marketing pages (not recommended... no, really, don't do that to yourself... ask me how I know).
In either case, it's again a question of "what do I want or need to maintain it". Choosing the right level of power vs simplicity, or abstraction vs transparency perhaps, is an architectural question about your app and business needs, not the language or ecosystem underneath it.
6) Vendor lock-in
You can host PHP anywhere. You can also host JS anywhere these days. In fact I'd argue there are more high-quality,low-cost JS hosts now than there ever were similar PHP hosts. Shared PHP hosts were a nightmare, because PHP was not easy to containerize for shared tenancy. JS hosting is cheap in comparison.
Most of the frameworks in either world are open-source. Not many are not-for-profit (Drupal is, but Laravel Forge/Forge and Vercel/Next have similar business models of open-source frameworks coupled with for-profit hosting).
In either case, though, it's really your application logic that's valuable (and even then, questionably so, since it'll likely end up completely rewritten in a few years anyway).
Ultimately we're all at the mercy of the browser developers. Google singlehandedly made shared hosting very difficult for everyone with the introduction by forcing HTTPS a few years back. It singlehandedly made the heavy JS frontend possible with its performant Javascript engine. WASM is still recent. WebGPU is on the horizon. New technologies will give rise to new practices, and new frameworks will soon feel old.
But JS is here to stay, because it's the only language that can natively interact with the DOM clientside. If your core business logic is written in almost-vanilla JS (or even JSX, by now), portability between JS frameworks isn't as hard as porting between different languages (like PHP to JS, or PHP to Ruby). Using it for both the client and server and in between just means fewer languages to keep track of, a shared typing system, etc. In that sense there's probably less vendor lock-in with JS than there is with PHP, which fewer and fewer companies and hosts support over time. PHP is overwhelmingly just Wordpress these days, which itself has moved to more dynamic React-based elements too (like in the Gutenberg editor).
I think the problem with the JS ecosystem is actually the opposite: not lock-in, but too many choices. Between the start and end of this post, probably five new frameworks were released =/ It's keeping up that's hard, not portability. You can copy and paste most of the same code and modify it slightly to make it work in another framework, but there is rarely any obvious gain from doing so. For a while there Next seemed like it was on track to becoming the standard JS framework, but then the app router confused a lot of people and now simpler alternatives are popping up again. For that much, at least, I can agree with the article: everything old is new again.