> since our single written source code is often executed on different environments and browsers That's still a lot easier than writing portable C has to suppor

> since our single written source code is often executed on different environments and browsers That's still a lot easier than writing portable C has to support variations in environment, compiler (w/ varying interpretations of the C standard over several decades), linker, make/build tools, CPU architecture and byte-sex (big-endian vs little-endian vs middle-endian), pointer sizes and alignment rules, integer sizes and alignment rules, incomplete and occasionally broken "standard" headers, and many more inconsistencies. And that's just for a simple system daemon or command-line tool. If you want a GUI, that's another giant mess for potability. > it's silly that we web developers should spend time to recreating basic wheels Of course. There are many solutions to that problem that don't require builds that depend on network resources controlled by 3rd parties. > JavaScript language itself is fundamentally flawed and the core APIs is a mess While that's debatable (worse platforms exist), it also misses the entire point. Nobody is saying that sharing the code for left-pad is a bad idea. Wrap it up properly into an extended-standard-library and distribute it with node/etc. What is conspicuously missing is any discussion at all about the costs of depending on 3rd party libraries. Adding a network, 3rd-party dependency to your build or deploy process is a huge risk that at the very least needs to be justified. Note that I'm not saying that using 3rd party libraries is bad; I'm saying it has a cost paid in additional risk. You can decide if that cost is a fair exchange for the benefits you gain from the library. Just remember that humans are terrible at evaluating risk, so it might be a good idea to limit how much risk you take on.