[throwitaway1123]

> One of those environments is a GUI which is naturally a good application for async. The other is not. Backend web development is still largely input -> process -> output. Node is just shoehorning JS in, and pretending that JavaScript's weaknesses are strengths.

Until you need to perform two or more IO operations at the same time (e.g. more than one of: database query, Redis query, HTTP request, file operation, etc). Then it becomes:

input -> Promise.all (or Promise.race, or Promise.allSettled, or Promise.any) -> output.

If you watch Ryan Dahl's original presentation introducing Node, you'll see that JS was explicitly chosen because of its asynchronous nature — it wasn't shoehorned in: https://youtu.be/EeYvFl7li9E?t=795&si=FG0yxaGoCgz1rqOX

> Not sure what you mean. There are a bunch of ways to run PHP

Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary: https://nodejs.org/docs/latest-v22.x/api/http.html#class-htt...

[ecjhdnc2025]

> Node doesn't require an upstream CGI server at all. There's a server built-in to the Node binary

Though you'll still want a process manager for this to make sure it stays up. Which it won't, over the long term.

PHP also has a built-in webserver, which you shouldn't use.

FrankenPHP is the better way to do this with PHP: you get a full Caddy build, with all that offers, with a built-in PHP engine.

[throwitaway1123]

The FrankenPHP binary also needs a daemon to manage it, which is why the docs recommend using Docker. So you end up with Docker (or SystemD or whatever you prefer), managing Caddy, which is in turn managing PHP. This is because the server which ships with PHP is documented with a big red warning that says something to the effect of "don't actually use this in production, this is just a dev server" [1]. Node's built-in web server is production ready, so you can safely cut out the reverse proxy middleman. I don't actually have any major qualms about the FrankenPHP stack, I was just trying to intuit what the original commenter meant when they said "standalone server".

[1] https://www.php.net/manual/en/features.commandline.webserver...

[ecjhdnc2025]

FrankenPHP doesn't proxy to the PHP dev server. It is a PHP SAPI process manager itself.

You should be able to run FrankenPHP as the front end server just fine -- Caddy is excellent and it's my production front-end almost everywhere anyway (the Let's Encrypt support alone is worth it).

Though depending on the deployment I sometimes use Apache and mod_php still for the backend; this is still modestly less painful if you want to use WordPress in the same environment.

There is absolutely no way I would put node at the front of any server; I'd reverse proxy to it as a matter of principle, with very locked-down routing. The security situation with node package dependencies is hilariously bad, and some other server should be managing HTTPS.

Personally I consider the NPM ecosystem to be a horrific side-road in web development, and I think by contrast PHP is at least honest about what it is and what it is not. The amount of cargo-culting advice around package management in NPM is frightening.

[throwitaway1123]

> FrankenPHP doesn't proxy to the PHP dev server.

I didn't say FrankenPHP proxies to the PHP dev server. I'm saying FrankenPHP is a Frankenstein amalgamation of the Caddy reverse proxy server and PHP, which is necessitated by the lack of a production server built in to PHP. Some languages/runtimes like Go (which Caddy is written in) and Node have production ready servers built in to their standard libraries.

> I'd reverse proxy to it as a matter of principle [...] some other server should be managing HTTPS.

I've used Caddy and it's great, but if I have Cloudflare or some other service terminating SSL and serving static assets, then I don't necessarily need Apache, Nginx, or Caddy acting as a middleman.

> The security situation with node package dependencies is hilariously bad

Most of the security issues involving NPM are related to client side JS, not server side JS. PHP doesn't run client side at all, so it's a bit of an apples to oranges comparison. If you're just doing traditional server side templating then there are plenty of rock solid frameworks. Hapi has zero third party dependencies and was designed by one of the authors of the OAuth spec for example.