Convenience is one

I've used redbird to create a local dev proxy that can run be via npm scripts (which were already in the repo) so our engineering team didn't have to run the entire constellation of docker containers if they were only working on frontend code, and the only setup required was `npm install` which they already needed to do

I do wish you could just `npm install nginx` though

how would npm install nginx be different from [yum|apt] install nginx?

Its a local installation, inside the folder, instead on the operating system. Also, other people will automatically install it when the package is saves inside the package.json or yarn file. You can also limit the version you want with these files, that the end user dont need to think about. Just yarn install :)

  serv() { docker run --rm --name "nginx-${1:-8000}" -p "${1:-8000}:80" "${@:2}" -v $PWD:/usr/share/nginx/html:ro caub/nginx-dev; }

this is what I do to run a local static server, you could run nginx with a config for proxying on docker as well

also yarn.. bleh, just npm, nowadays it's even faster (on linux)

source of caub/nginx-dev: https://github.com/caub/docker-images/tree/master/nginx-dev

I'd like to double-down here on the benefit of having a local installation of a reverse proxy vs what yum/apt gives you.

Though this is the main reason I use Caddy over Nginx. I have my Caddy executable and config for all my projects right there in the home root. I ssh into one of my cheap vps and I'm an `ls` away from remembering how to configure it.

Meanwhile, every time I use Nginx I have to remember where the different folders are that it uses, where the configs are, and how to even start/stop/reload it. I usually symlink its config to the home root and paste a few common commands into ~/README.md for future-me.

Obviously, at a larger scale where you're automating your machines, this doesn't really matter. But at any scale under that where you're sshing into different machines, it becomes a nice to have.

On top of what others said, ease of use during (team) development through simplicity and consistency - some developers have Macs, some have Linux, some have Windows - and no one wants a work project altering their system anyhow.

As opposed to node with runtime implemented in C++?

"Because they can" is often the most fitting answer. Even a tiny feature is worthy to start a totally new project with a fancy name.

To be precise, I meant "why not use ..." comparison. I don't mind why the project was started. Whatever the reason, well done for getting it to this stage! But the other side - why should we be interested - is interesting :-)

One reason could be that it might be easier for node.js devs to read and understand its source code. I don't use the software nor have read its source code, though.

Sometimes I think that there are not enough of real problems to solve in the js world.

Too many people pumped into a tight space of the frontend development are creating in there another copy of the whole infrastructure while limited by the tools that weren't designed for that.

Node was designed to build networking applications just like this.

No, node was the realization that JS’s concurrency model could be applied to applications like this.

No? You're not even disagreeing with the parent.

I am, but it is subtle.