Echo JS 0.11.0

<~>

jaleksic 2824 days ago. link 1 point ▲ ▼
The downvotes are unclear to me. It's not a bad article, regardless of Module type preference..
xat 2824 days ago. link 1 point ▲ ▼
The module situation in the JS ecosystem is terrible these days. They should have just choosen CommonJS or AMD to be the standard instead of inventing something new.
Yes, tree-shaking is nice... but it does not justify the fragmentation we currently have and all the build/transpile insaneness.
tracker1 2824 days ago. link 1 point ▲ ▼
CJS/Node modules really can only work via pre-bundling solutions... AMD is pretty bad in it's own right as well, though slightly better for the browser case.

The ES2015 module syntax offers the ability to determine loading as a pre-process step.  Though in practice most aren't using proper reference paths, so you're stuck using pre-bundling, similar to CJS.  Also, you can't conditionally require modules as you can with CJS.  Some benefits are the ability to have better tree shaking with bundlers.  As it stands, the tooling is a work in progress.

If ES2015 modules were supported in browsers from earlier on, then they would have been used over either CJS or AMD.  And HTTP2 would have been *HUGE* in terms of performance.
sylvainpv 2824 days ago. link 1 point ▲ ▼
IMO the JS module situation has always been terrible, and ES6 modules are the best way out we have. What made the situation complicated is not only the fight between AMD and CommonJS, but also the differences in the libraries implementations and the arbitrary use of global keywords such as "require". Picking one of these implementations wouldn't help at all, it would break backward compatibility and would result in even more confusion.

Once we have browsers native support (which should happen soon based on the recent announcements), AMD and CommonJS will no longer be needed and will probably disappear in a few years. That should be enough to convince people to bet on ES6 modules for their next project.