es6features
es6features copied to clipboard
lukehoban
Programmatic module loader API Specification?
It would be great if the documentation specified the source specification for the programmatic module loader API since the draft ES6 specification you link to does not include that API, and I can find no definitive source specification anywhere on the Web.
Any pointers much appreciated.
The module loader API was actually removed from ES2015; it should probably just be removed from this repo.
Ouch, that wasn't the answer I was expecting! So the module loader API is dead, yet the Internet is strangely quiet on the subject; hopefully somebody writes an article, or people luck out and end up here.
Anyway, thanks so much for letting me know.
Erm, so I'm struggling to come to terms with this loss. If true then this would mean that even System.import() will no longer be supported, and it would therefore be impossible to dynamically import modules into a program?
Worse, there's no way for import to even load modules, since it doesn't have a loader to consult.
Eventually there will be a loader spec, but until then ES2015 just specifies the syntax, and the syntax does nothing. (That is, the spec contains points where it's like "consult the host environment to do something useful here.")
Worse, there's no way for import to even load modules,
Wow, I'm really struggling to understand what that even means. How can anybody use ES2015 if import doesn't load the modules? Are we back to bundling everything again rather than using HTTP/2 to load them on-the-fly?
And, if we are back to bundling our modules, what does the bundling format look like given that the module loader polyfills seem to all be using System.register(), which is the module loader API again?
But CommonJS and AMD both use function invocations to bring dependencies into a module, which can be done in JS, whereas import is a keyword. If the browser doesn't load the module that I import then it at least still needs to hook up my variable references so I can use the thing I've imported right? And, to do that, I would imagine there must be some bundling format so that the browser knows which modules are which, so it can resolve import statements?
And, ... you know that April fool's day is the first day of the month and not the last right? Just checking...
Maybe I wasn't clear. In a browser that implements ES2015, using import will parse, but will not work. You can't use import, basically. So go back to using require or whatever.
Wow, this is huge! I'm blown away by this!! Final question: can you point me and everybody else to a transcript of the meeting (or the minutes) where this decision was made?
https://github.com/tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#loader-pipeline
Lovely, thanks for the heads up :+1:. This paragraph was particularly interesting to me:
YK: The loader pipeline will be done in a "living spec" (a la HTML5) so that Node and the browser can collaborate on shared needs.
which makes me think that the ES6 module loader polyfill (or another polyfill that becomes more popular) will end up informing what the final module loader API ends up looking like, given that you are seeking real feedback based on what really works in both the browser and Node.js, and given that Babel already supports bundling in a format that this polyfill and others can work with (as specified in System.register() explained).
It's just good to have an inkling of what's happening in the future so we can better align ourselves with that future...
@domenic Does this mean that any implementation (CommonJS, SystemJS, AMD, etc) has equal opportunity to become the underlying standard when/if a module spec finally becomes official?
@trusktr there many way to import module with a numbers of optimization based on different scenario. So its a good decision to offload the process of including the module to third parties.
Webpack, Browserify, Install, JSPM. I think they currently all transform code into a CommonJS-like format (if not CommonJS itself) behind the scenes.
Are there any pro's and con's choosing one over the others? I heard that JSPM is built on top of SystemJS.
I'd suggest you just give each one a try and see which one you like more. There's other ones too, like duo.js and rollup.js. Trying them out is the best advice.
You should also look at what is preferred for whatever environment you happen to be developing in. For example, the React community tends to prefer Webpack whereas Aurelia would have you use JSPM / System.js.
