Docker docs:
Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses. Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration.
This is less of an issue with JS, but say you're developing this C++ application. It relies on several dynamically linked libraries. So to run it, you need to install all of these libraries and make sure the versions are compatible and don't cause weird issues that didn't happen with the versions on the dev's machine. These libraries aren't available in your distro's package manager (only as RPM) so you will have to clone them from git and install all of them manually. This quickly turns into hassle, and it's much easier to just prepare one image and ship it, knowing the entire enviroment is the same as when it was tested.
However, the primary reason I use it is because I want to isolate software from the host system. It prevents clutter and allows me to just put all the data in designated structured folders. It also isolates the services when they get infected with malware.
Ok, see the sandboxing makes sense and for a language like C++ makes sense. But every other language I used it with is already portable to every OS I have access to, so it feels like that defeats the benefit of using a language that's portable.
I think it's less about making it portable to different OS, and more different versions of the same os on different machines with different configuration and libraries and software versions.
it does not solve portability across OS families. you can't run a windows based docker image on linux, and running a linux image on windows is solved by starting a linux VM.
Oh, fair. That's a good point.