Rationale for dropping ModuleImport syntax?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Marius Gundersen

> I'd say we only support named exports, something like this: https://gist.github.com/mariusGundersen/88a4c5690e08da0d07f6

If you do that, the real-world consequences will be even worse. Nobody (to a first approximation) will use ES6 modules at all, as they will be entirely incompatible with how modules are used today by both AMD and CommonJS communities.

The fact is, static verification of exports---which is notably different than static analysis of imported module IDs---is not something any noticeable segment of the existing module-using community has been crying out for. Nobody has even developed a linter to check for that sort of thing! So it's largely something that TC39 came up with and championed as important, meeting with indifference from the (majority of the) community. It's a nice side benefit of certain usage patterns of ES6 modules, but the recent removal of `module x from "y"` tips the scales from "slightly inconvenient to adapt to" toward "too inconvenient to use in practice."

Remember, our target audience is not people who read es-discuss, sometimes program in static languages, and are intimately familiar with the tradeoffs between different module systems and usage styles. It is existing AMD and CommonJS communities of real-world JavaScript practitioners, who are already confused and exasperated as to "why doesn't that silly committee just adopt CommonJS" (or AMD).

I've worked hard over the past year or so to try to convince some of those practitioners of the benefits of statically-analyzable imported module IDs, which is something they can understand (given how it makes tools like browserify more feasible, and prevents the edge-case failures of AMD's CommonJS sugar). I've met with some mixed success, despite the committee's frankly confounding focus on statically-verifiable exports, or magic `with`-esque aliasing-bindings, throwing up roadblocks along the way. But it's an extremely delicate balance, and at this point I am still not convinced (even without the recent round of usability-reducing changes) that ES6 modules have a chance in the marketplace of ideas.