We need them so you can pick and choose the one that works best for your current project.
But that points to an important aspect of the platforms-game: The interface between the runtime and everything else should be standardized, to support true pick-and-choose.
choice is sometimes not a good thing. This is just fragmentation for fragmentations' sake, imo. The bun team could have contributed to node. The deno team could have too (once they did a 180 and decided deno would be node compatible). Instead we have a de-facto standard with a bunch of subtly incompatible implementations.
I'm also happy using Common-JS syntax on the Node.js. In the odd case that both the client (browser) and the server (Node.js) should run the same code, it can easily be accomplished with minimal amount of code-duplication. And such code-duplication can actually be good reducing the number of dependencies that could break in some future version of the software.
Just saying don't throw out the Common-JS sub-system with the bathwater.
The problem with ES6 modules (imo) is it does not support sync loading of dynamic imports, so you have to figure out how to handle the Promise.
I believe it indicates a healthy market and pushes competition and better outcomes for customers.
In this case, Deno pushed Web primitives for Node.js and Bun pushed forward on speed (and helped Node.js work on their numbers better).
This have a similar analogy with browsers. Back then when Internet Explorer was the only supported browser, the websites were not evolving as fast. When Firefox pushed it forward and then Chrome, customers won (better and faster sites).
