[baby]

> I was surprised to learn that other languages didn't work the same way, when integrating into a web server

Oh boy... I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different, with php you just needed to drag & drop your files in the "public" folder.

[neurostimulant]

It's pretty simple really. With php, your php sites consist of some php files that will be run by a webserver (apache, php-fpm, etc). When the webserver receive a http request, it will executes a php file that matched the request url, pass it the request body as input and send back the output as request response. On other languages, your app is typically deployed as the webserver itself, handling request directly (or indirectly with a reverse proxy in front of it) without executing any external process or terminating after each request.

The php model is simpler and easy to reason with, but many use cases in modern web development is not possible in this setup and requires you to write your app as a long-running webserver process (e.g. websocket model).

[http-teapot]

> I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different

Coming from PHP and having used a bunch of different languages I can understand what you are saying.

Unlike PHP, the other languages run in a process that listens on a port (80, 443 or another). The single process continuously run and handles multiple requests.

Back then, I still had to use NGINX or Apache with PHP, and in retrospect I find that more difficult to understand than a script that listens on a port.

[francislavoie]

Caddy largely solves that problem. A config for a PHP app is usually about 4 lines long, see the example on this page: https://caddyserver.com/docs/caddyfile