Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programmatic module loader API Specification? #75

Open
dchambers opened this issue Apr 30, 2015 · 18 comments
Open

Programmatic module loader API Specification? #75

dchambers opened this issue Apr 30, 2015 · 18 comments

Comments

@dchambers
Copy link

@dchambers dchambers commented Apr 30, 2015

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.

@domenic

This comment has been minimized.

Copy link
Contributor

@domenic domenic commented Apr 30, 2015

The module loader API was actually removed from ES2015; it should probably just be removed from this repo.

@dchambers

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented 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

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented 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

This comment has been minimized.

Copy link
Contributor

@domenic domenic commented 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

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented Apr 30, 2015

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?

@domenic

This comment has been minimized.

Copy link
Contributor

@domenic domenic commented Apr 30, 2015

You use it the same way you use ES5. CommonJS, AMD, globals, whatever.

@dchambers

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented 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 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...

@domenic

This comment has been minimized.

Copy link
Contributor

@domenic domenic commented 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 use import, basically. So go back to using require or whatever.

@dchambers

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented 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

This comment has been minimized.

@dchambers

This comment has been minimized.

Copy link
Author

@dchambers dchambers commented Apr 30, 2015

Lovely, thanks for the heads up 👍. 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...

@trusktr

This comment has been minimized.

Copy link

@trusktr trusktr commented 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

This comment has been minimized.

Copy link

@wajatimur wajatimur commented 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

This comment has been minimized.

Copy link

@playground playground commented Jan 3, 2016

What are some of the third party loading libraries would you recommend?

@trusktr

This comment has been minimized.

Copy link

@trusktr trusktr commented 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

This comment has been minimized.

Copy link

@playground playground commented 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

This comment has been minimized.

Copy link

@trusktr trusktr commented 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

This comment has been minimized.

Copy link

@knpwrs knpwrs commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.