Not surprised you're being downvoted for calling out HN for it's anti-JS bias.
But there are indeed still several module systems in use:
* globals (i.e. none)
* CommonJS
* AMD (just kidding, nobody uses this for new code)
* UMD (which mixes AMD, CommonJS and globals)
* SystemJS
* ES modules (via Webpack, browserify, whatever)
* ES modules in the browser (which behaves slightly differently)
That's 7 so I'll stop there. Yes, it's cheating a bit but of those I'd say AMD and UMD are the only ones that are dead as a doornail (for new code anyway -- plenty of libraries still use UMD for nostalgia). You'll only end up using one of them (or maybe two if you mix ES imports and CommonJS requires for some reason) but which one depends on which part of the ecosystem you end up with.
It seems that most of the community has adopted Webpack as the one true bundler for apps. Rollup is generally seen as better for libraries though.
Angular I think still promotes SystemJS, React is half-way between CommonJS and ES modules (via Webpack/Babel). I have no idea what Ember is doing.
If you want to add type safety, Angular strongly favors TypeScript while React is slanted towards Flow for obvious reasons.
The JS ecosystem is complex. Even if you cut out all the nostalgic stacks (MVC with Backbone and jQuery is still cool, right kids?) there are still many paths to pick from.
But I agree with your final conclusion: the reason the JS ecosystem is so complex is that it has changed a lot over the years and has seen massive improvement while still maintaining backwards compatibility at a language level with tons of legacy code that's still out there and still running in production.
> AMD (just kidding, nobody uses this for new code)
Lulz, our Oracle-owned ERP system chose AMD for its module system less than two years ago. All new code will use AMD here for, I expect, the next decade.
But there are indeed still several module systems in use:
* globals (i.e. none)
* CommonJS
* AMD (just kidding, nobody uses this for new code)
* UMD (which mixes AMD, CommonJS and globals)
* SystemJS
* ES modules (via Webpack, browserify, whatever)
* ES modules in the browser (which behaves slightly differently)
That's 7 so I'll stop there. Yes, it's cheating a bit but of those I'd say AMD and UMD are the only ones that are dead as a doornail (for new code anyway -- plenty of libraries still use UMD for nostalgia). You'll only end up using one of them (or maybe two if you mix ES imports and CommonJS requires for some reason) but which one depends on which part of the ecosystem you end up with.
It seems that most of the community has adopted Webpack as the one true bundler for apps. Rollup is generally seen as better for libraries though.
Angular I think still promotes SystemJS, React is half-way between CommonJS and ES modules (via Webpack/Babel). I have no idea what Ember is doing.
If you want to add type safety, Angular strongly favors TypeScript while React is slanted towards Flow for obvious reasons.
The JS ecosystem is complex. Even if you cut out all the nostalgic stacks (MVC with Backbone and jQuery is still cool, right kids?) there are still many paths to pick from.
But I agree with your final conclusion: the reason the JS ecosystem is so complex is that it has changed a lot over the years and has seen massive improvement while still maintaining backwards compatibility at a language level with tons of legacy code that's still out there and still running in production.