I see this as the opposite and find it adds quite a load of complexity and prevent to do some form of optimization in an app that has its own server.

It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.

I don't find this to be true at all.

> you need an external server

Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.

What are you talking about?

Lots of languages and frameworks make it easy to be self-hosted with there own server. In Python, .net, Go, Rust this is quite common.

This means that your app can be a self-contained app + server and the server part can have some business logic as well.

With Go, .net, Rust apps (and potentially others) that's quite nice to be able to produce a single binary app that you can just run anywhere without installing any framework or setting up any external server and it's ready to listen to incoming queries.

That can even be a good enough setup for home things that are not exposed to the web and where setting up reverse proxies could be overkill.

Good point, but just to nitpick: I think that ipfs-js let's your external server be a process in someone else's browser, which is about as unserverlike as servers get.

You do not need an _external_ server for a lot of languages. If you use node for example you can use the express package to run a custom server, or embedded tomcat for java

I suppose, but I've never encountered a production site that was using Gunicorn or similar as a true server. Usually that's coupled with something like Nginx or HAProxy.

So yeah, you technically don't need one for Ruby or Node.js, but I sure would.

PHP has a built in web server you can launch from the CLI and run the script. `php -S <address:port>`

The kind of optimizations you would do in an application server would prevent you from scaling pass a single server

PHP does have it's own built-in server as well, although it is not really meant for production use.

Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.

My bad, I didn't know that about PHP build in server

I only host one PHP app now (Nextcloud) and it has definitely been a bit of a pain in comparison with other things I self host.

Nextcloud is more complex than most PHP apps.

Async code is a good way to achieve some level for performance in I/O bound workloads, but it's a pain for the programmer. Because of that I wouldn't say that it's necessarily a good thing that JS is async-first.

In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.

>In my opinion, high level languages should not expose async primitives to the programmer

Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.

Before being async as in async/await Javascript was also async as in having an external event loop and being event driven.

Yup. Go too, but the programmer doesn't need to know it.

That's not quite a language feature though: one can write (Fast)CGI or similar programs in any common language.

I've never actually tried writing CGI scripts with a non-PHP language (I've not really seen the point since it's usually more ergonomic to just use a language native-server interface like Python's WSGI).

Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).

>Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level?

I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.

> Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level?

I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.

Forgive me for going a little off topic here but is it really true that JS was async-friendly from day 1? When I started using JS seriously 8 years ago, async code was horrible (callback hell, etc.) The web standards guys retrofitted native async way after the matter.

Doesn‘t this more or less mean "the only execution environment is event based, has a run loop outside of your control and calls your code whenever it wants" and "there is no busy sleep". So it was callback based from day one. Is that the same as async? I think it is?

That makes sense, thanks! It has indeed been run in a loop from the start despite the poor ergonomics - I did not think of it in that light.

async/await is just syntax sugar around promises which are a just a nice way of organizing callbacks, so yes I'd say it's true.

Probably more accurate to say it was async from day one. Which people probably realized the first time they had to deal with setTimeout

The original promises syntax and chaining in ES6 were not particularly user friendly.

Isn't that exactly the same as most web frameworks except without a few lines of code saying something like "when this URL is accessed, run this function to handle it"?