The comment I wrote at a higher level in this same thread is, ultimately, a criticism of NOT using a statically compiled, statically linked language (because a

The comment I wrote at a higher level in this same thread is, ultimately, a criticism of NOT using a statically compiled, statically linked language (because a form of tree shaking like original commenter suggested is already part of the linking step there, except for DLLs). And yet, full disclosure and admitting to cognitive dissonance, for a (hobbyist) C++ game engine I'm currently working on that targets Emscripten for a web build and native for Debug build, I'm considering not even having a native-Release build at all. The idea being if it's web-first and the native build being only for developer use for debugging, I could do things like supporting only one desktop graphics API (e.g. just DirectX) and optimizing the native graphics pipeline for simplicity over performance. End users would/could just use the web version. Granted this is a bit different because I wouldn't be distributing a browser too a la Electron; it would just use the browser the end user already has. Just thought it's interesting that it's easy for me to criticize others, but with the choice of how to spend my own limited developer time (my free time) it's looking like this way of doing it makes the most sense.