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

Comments: 2015/02/13/how-to-know-when-es-modules-are-done/ #30

Closed
jrburke opened this Issue Feb 13, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@jrburke
Copy link
Owner

jrburke commented Feb 13, 2015

@xjamundx

This comment has been minimized.

Copy link

xjamundx commented Feb 13, 2015

  • Currently using ES6->AMD transpilation with 6to5 at PayPal (not everywhere) and it's great! Love the new syntax and am really happy with it.
  • Agree the export default thing and then .default thing is super weird (and appreciate 6to5 just letting you basically ignore it)
  • Is the loader part even being handled by TC39 or was it WhatWG?
  • De-coupling modules from files / inlining is an interesting point (for minification, etc on the web, though...webpack)
  • Any word on timelines for browser (and then obviously v8) support? Presumably, we're over a year away?

For me. I'm really glad to have a unified syntax for this stuff. Minor changes and improvements will be made over time, but I really love being able to write the same module syntax on the web as on the server and can't really imagine going back at this point.

In my head 6to5 is more like a polyfill than a transpiler. It's enabling future syntax everywhere. I get that it's actually transpiling a bunch of stuff, but the fact that it's staying current with the spec means I can trust using it and know that one day fingers crossed I can turn it off and everything will just keep working.

Hopeful for the future! 🚀

@jrburke

This comment has been minimized.

Copy link
Owner Author

jrburke commented Feb 13, 2015

@xjamundx I don't have any information on where the specs will end up or how long it will take.

Glad you are happy with the tool you are using. If you do not have a use case that runs into the issues outlined I can see where it would be nice. It is not required to get the same module syntax on both browser and server (other tools work for AMD or CJS modules), but that definitely comes down to a personal style choice.

@xjamundx

This comment has been minimized.

Copy link

xjamundx commented Feb 13, 2015

Yeah I mean we still use require.js to dynamically load stuff, though maybe we'll shift to webpack someday. I think the dynamic loading story is definitely not solved yet (at least not clearly) by ES6 modules, but happy syntax and coding consistency is still a win +1. I suppose with 6to5 we could easily just use CJS on the client-side as well, maybe we'll try that :)

@csnover

This comment has been minimized.

Copy link

csnover commented Feb 16, 2015

maybe we'll shift to webpack someday

I see a lot of people doing this and it’s really unclear to me why. What do you know that webpack provides that isn’t available from tools like r.js?

suppose with 6to5 we could easily just use CJS on the client-side as well, maybe we'll try that :)

Could you explain more about why would you do this? Since AMD is designed for asynchronous/client-side module loading systems, doing this seems like it would require you to add yet another layer of abstraction (like browserify) with no gain?

@xjamundx

This comment has been minimized.

Copy link

xjamundx commented Feb 16, 2015

  • r.js has helped push the web forward in great ways, but it's fundamentally incompatible with NPM.
  • webpack / browserify have great support for NPM
  • webpack is the only tool (I'm aware of) that has support for both NPM and async require() (see: https://github.com/petehunt/webpack-howto#9-async-loading)

But this is all an aside. We already are using ES6. We love ES6. So we need a tool like 6to5 (now Babel) to transform our code. If we're already transforming our code, it seems silly to continue to use a syntax (AMD) that's non-standard, bulkier and not the same as our server code. Based on some of @jrburke originally comments/arguments, I'm debating going back (from ES6 modules to) CJS for our module syntax, but ultimately the goal is the same:

One universally accepted javascript module format on the client & the server

@csnover

This comment has been minimized.

Copy link

csnover commented Feb 16, 2015

r.js has helped push the web forward in great ways, but it's fundamentally incompatible with NPM.

How so?

webpack / browserify have great support for NPM

What does this mean? npm is a package manager, not a module format nor a module loader.

webpack is the only tool (I'm aware of) that has support for both NPM and async require() (see: https://github.com/petehunt/webpack-howto#9-async-loading)

Again, I don’t understand what “npm” support is. Could you please explain what you mean?

One universally accepted javascript module format on the client & the server

If this is your goal, AMD works for this today too. I’ve been writing cross-platform apps since 2011, using an AMD loader on the client and an AMD loader on the server, with the added benefit of being able to also have asynchronously resolving modules using loader plugins, which is impossible with Node.js sync-only loader.

Please don’t read into any of these comments that I am trying to get into any sort of holy war, I am just trying to understand why people think these things, because maybe I am missing something.

@xjamundx

This comment has been minimized.

Copy link

xjamundx commented Feb 16, 2015

  1. I can't npm install module and then define('module', function(module) { without extra config or a specially configured module, because of path resolution differences with NPM as far as I understand. Why do I care, because most likely someone already has solved my problem on NPM :)
  2. The key to a unified module format is the "universally accepted" part. You could argue that AMD won round 1 of the module format wars on the web and CJS won round 1 on the serverside (in terms of pure popularity), but for a unifying format that we use everywhere it's looking like CJS or ES6 and I think most of us are betting on ES6. (See ember, react, etc.)
  3. Agree with @jrburke though that the ES6 module spec doesn't solve all of our problems, so we need to keep iterating there, but the syntax is pretty solid and I don't mind using it even while we iron out the details :)
@httpete

This comment has been minimized.

Copy link

httpete commented Mar 13, 2015

One universally accepted javascript module format on the client & the server - is the holy grail.I think it's fair to say that the array syntax and function argument order syntax is not as accessible to the masses. I hope typescript will be the bridge that we need to get us from here to there.

@joeedh

This comment has been minimized.

Copy link

joeedh commented Apr 1, 2015

I use ES6 modules in my (in-house, far inferior to traceur or babel--but I'm stuck with it) transpiler. I had never thought about concatenation; I do concatenate, but since I'm compiling to ES5 anyway there obviously are no syntax barriers to concatenating multiple modules together.

Has there been any progress on this front?

@jrburke

This comment has been minimized.

Copy link
Owner Author

jrburke commented Apr 1, 2015

@joeedh not that I am aware of. That would be question likely to ask on es-discuss, as I expect it would need language syntax to properly support. In the past, there did not seem desire to specify it. I have asked more recently privately but did not receive a response.

@jrburke jrburke closed this Mar 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.