Open
Description
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.
Activity
domenic commentedon Apr 30, 2015
The module loader API was actually removed from ES2015; it should probably just be removed from this repo.
dchambers commentedon Apr 30, 2015
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.
dchambers commentedon Apr 30, 2015
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?domenic commentedon Apr 30, 2015
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.")
dchambers commentedon Apr 30, 2015
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?domenic commentedon Apr 30, 2015
You use it the same way you use ES5. CommonJS, AMD, globals, whatever.
dchambers commentedon Apr 30, 2015
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 Iimport
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 resolveimport
statements?And, ... you know that April fool's day is the first day of the month and not the last right? Just checking...
domenic commentedon Apr 30, 2015
Maybe I wasn't clear. In a browser that implements ES2015, using
import
will parse, but will not work. You can't useimport
, basically. So go back to usingrequire
or whatever.dchambers commentedon Apr 30, 2015
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?
domenic commentedon Apr 30, 2015
https://github.com/tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#loader-pipeline
dchambers commentedon Apr 30, 2015
Lovely, thanks for the heads up 👍. This paragraph was particularly interesting to me:
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...
trusktr commentedon Dec 15, 2015
@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?
wajatimur commentedon Dec 20, 2015
@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.
playground commentedon Jan 3, 2016
What are some of the third party loading libraries would you recommend?
trusktr commentedon Jan 3, 2016
Webpack, Browserify, Install, JSPM. I think they currently all transform code into a CommonJS-like format (if not CommonJS itself) behind the scenes.
playground commentedon Jan 3, 2016
Are there any pro's and con's choosing one over the others? I heard that JSPM is built on top of SystemJS.
trusktr commentedon Jan 4, 2016
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.
knpwrs commentedon Jan 4, 2016
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.