I'm the same kinda dinosaur, but I have to disagree with the following: > Now, modern javascript packages for the web also use includes because it's part of NP

I'm the same kinda dinosaur, but I have to disagree with the following: > Now, modern javascript packages for the web also use includes because it's part of NPM and the Node ecosystem. And as a result, there has to be a transpiling/build step to convert "Node" javascript to "frontend" javascript, or some other language to frontend javascript. At first, I would agree, but with ES2015+ the import system isn't too different or at least shares a lot with CommonJS. Since that's the future of JS modularization, I think it's important to embrace it. However, there is one area where the TC39 committee, along with browser vendors/Node, really messed up is the releasing of the module system with so much undefined or all over the place. For example, the lack of a bundling strategy. Every person I've talked to about this has just said "oh, http2 will take care of it". Really? Even if http2 supports multiple connections, there will either need to be multiple round-trips to the server for further dependencies (which, physics puts a limit on the speed that can happen at), or you need to calculate on the server and send over what's needed. So I think these module bundlers are essentially doing that at build time (which sucks for runtime dynamic inclusion of resources). Then there's the whole .mjs fiasco with Node. Since committees are so often slow to update (for valid reasons, many times), and miss many valid use cases, I think the new world of frontend development will include some sort of tooling like this. It should, God willing, start to simplify (maybe kind of like how npm scripts are becoming more preferred to gulp and the like).