The sibling commenter covered the list well. To go into a little extra context on the reasoning:
fetch: Browser fetch didn't exist when NodeJS introduced its http built-ins. Many NodeJS libs are built on top of http built-ins, so replacing them would be a nightmare. Adding browser fetch on top of the existing http built-ins would similarly just give NodeJS a massive API surface area with cconfusingly duplicated functionality.
ESM + web import semantics: NodeJS was part of the "commonjs" movement that invented Javascript module importing. Module imports are an incredibly complex problem and hard to get right. Browsers took the hard-learned lessons from commonjs & nodejs and redesigned better modern APIs. NodeJS has been slowly trying to add support for the much improved browser web import semantics, but doing so while maintaining backward compatibility with their radically different commonjs APIs is a nightmarish challenge (they're working on it though, progress is good).
WHATWG streams: similar story to the import/commonjs situation. NodeJS basically "invented" streams in JS, and the WHATWG API is a newer design based on NodeJS lessons.
WebCrypto: Sibling comment is incorrect here actually: NodeJS & Deno both support this[0]
> I definitely would say I understood require better
ESM modules are in many ways "harder" to use than commonjs, but I think this comes down to something slightly intangible but very similar to the static-typing -vs- duck-typing discussion (duck-typing is more obviously intuitive and quick-to-do-what-you want, but static-typing has more wide-reaching architectural benefits for scaling projects).
CommonJS is a more "intuitive" design: what you might expect someone to design first-time-around. ESM is a more thought-through design: the initial "hurdles" to its use bring long-term benefits.
> ESM modules are challenging to [...] monkeypatch
This seems like a feature though
> I feel like the ESM implementation is more "magic" than require
How so? I'd say I feel the opposite.
> importing a .json file
Is this supported by browsers or is it a NodeJS extension?
Just for anyone tracking progress, the actual feature proposal is here: https://github.com/tc39/proposal-json-modules - the assertions proposal is just a security check on top of such modules.
fetch: Browser fetch didn't exist when NodeJS introduced its http built-ins. Many NodeJS libs are built on top of http built-ins, so replacing them would be a nightmare. Adding browser fetch on top of the existing http built-ins would similarly just give NodeJS a massive API surface area with cconfusingly duplicated functionality.
ESM + web import semantics: NodeJS was part of the "commonjs" movement that invented Javascript module importing. Module imports are an incredibly complex problem and hard to get right. Browsers took the hard-learned lessons from commonjs & nodejs and redesigned better modern APIs. NodeJS has been slowly trying to add support for the much improved browser web import semantics, but doing so while maintaining backward compatibility with their radically different commonjs APIs is a nightmarish challenge (they're working on it though, progress is good).
WHATWG streams: similar story to the import/commonjs situation. NodeJS basically "invented" streams in JS, and the WHATWG API is a newer design based on NodeJS lessons.
WebCrypto: Sibling comment is incorrect here actually: NodeJS & Deno both support this[0]
[0] https://developer.mozilla.org/en-US/docs/Web/API/Crypto