Hacker News new | past | comments | ask | show | jobs | submit login

Does this include native module import/export? I never saw anything to suggest they were even working on that.



Module import/export syntax was in ES6, but the browser implementation has not yet been standardized.


Well, it's been standardized, but implementation work is still ongoing. Details at https://blog.whatwg.org/js-modules


I'm confused by what it means that the semantics of imports weren't part of the spec yet. Do you mean polyfills like es6-module-loader (https://github.com/ModuleLoader/es6-module-loader) were just guessing how modules would behave?


The wonders of standards: the standards committee for JS language syntax (ECMA TC39) is a different standards committee from the committee for Browser behaviors like loading (WHATWG). (So many standards bodies to choose from!) The WHATWG Module Loader spec has been slower to be "finalized" and adopted than the ES2015 spec.


Although your larger point stands, about the division of responsibilities, it's important to distinguish "specifying browser module loading" from the Loader spec draft.

The loader repository at https://whatwg.github.io/loader/ is an experimental proving ground, as noted by its title ("A Collection of Interesting Ideas") and its Status section ("This document is a work in progress and dreams of becoming a living standard."), as well as the fact that it's in the whatwg.github.io namespace instead of the spec.whatwg.org namespace. To my knowledge no browser implementers have begun implementation of the experimental ideas here.

Contrast that with the agreed-upon work in the WHATWG HTML Living Standard discussed at https://blog.whatwg.org/js-modules, which is relatively finalized and is being actively implemented now in all browser engines.

I think we will see a gradual stabilization of the experimental ideas in the Loader spec, either in the Loader spec itself (with the stable ideas staying, and the experimental ones moving to a supplementary document) or by moving the relevant spec text into other locations (HTML and/or ES, probably). For example, I would hope that we will soon see a very simple promise-returning `importModule("./foo.js")` async module loading API, far ahead of the loader's more experimental in-browser-transpilation APIs or create-a-module-from-scratch-reflectively APIs. That could be done either by specifying it in the Loader spec, or by specifying it in ES with a call-out to a HostFetchModule() abstract operation, which HTML then specifies for browser hosts.


> Contrast that with the agreed-upon work in the WHATWG HTML Living Standard discussed at https://blog.whatwg.org/js-modules, which is relatively finalized and is being actively implemented now in all browser engines.

Just to clarify, unlike TC39, the WHATWG HTML ("Living Standard") spec requires no consensus at all in order to add new features. Consensus is arrived at once all implementers have implemented the relevant features to the stable versions of their browsers.

To say that what is in the spec has consensus at the same time as browser implementers are beginning implementation (and expressing some concern over details) gets the WHATWG process backwards.


That's not correct, Yehuda. For HTML especially, we work on a rough consensus model wherein features are not added to the spec unless they have multi-vendor implementation interest and review.

If you'd like to analogize to the TC39 process, features are merged into the HTML Standard once they've reached TC39 "stage 3".


So are you saying that, for example, the change to CORS from <script> in <script type='module'> has multi-vendor consensus?


Yes, that's exactly correct. Babel, polyfills, etc. were all just guessing at the future.


When TC39 creates ES modules, it's re-inventing the wheel ("The node community has already made modules that work, why'd you make a new one??").

When the Babel community creates a module loading approach, it's guessing at the future ("The spec is the law! When the community makes something, it's guessing at the law!").


I wouldn't say es6ml was "guessing", it was based on the old loader spec that was removed from ES2015, and was quite accurate. It's no longer relevant though, since whatwg/loader is quite different.


Import/export has been postponed AFAIK.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: