4 ms·

I think it can be a bit difficult for users of compile-to-JS setups to understand why this is better. As of right now, one can just `import foo from './bar';` a

I think it can be a bit difficult for users of compile-to-JS setups to understand why this is better. As of right now, one can just `import foo from './bar';` and the compiler just makes it work. This has become fairly tried and true. What might be confusing is that node's internals, and perhaps their design goals do not align with this paradigm. While I'm certain that they have reasons, it's going to be awfully hard to convince developers. (It already has been, look at the backlash on `.mjs`.) The solution? Continue to use TypeScript/Webpack/ESMloader forever. I personally like the semantics of importing the way it currently works. If it never works like that natively? Fine.

snek 8y ago
The issue is that transpilers didn't implement correct ESM (both ts and babel have opt in flags to enable more-correct-mode, but its still not 100%). they implemented the syntax but forgot about the actual semantics like dependency graph verification and such. Node is an actual implementation of js and so we must perform these tasks, even while transpilers don't.
- efdee 8y ago
  Honest question: Does anybody actually care that it doesn't?
  - snek 8y ago
    I don't think its as much a matter of people caring or not as it is that node is implementing ecma262 esm, not babel esm or typescript esm, etc.
    - nobleach 8y ago
      What happens if people seem to prefer the babel-esm semantics? I'm not saying that babel's semantics ARE better, but what if developers prefer them?
      - snek 8y ago
        then they can continue using them, and not use the real esm semantics? i don't think anything would change for them.
  - rictic 8y ago
    It matters. Projects that don't support IE ≤11 could ship ES Modules to the browser today. However, you can't ship most code that's written as "es modules" because this code is typically written for a transpiler rather than a real runtime modules environment. Some of this is a limitation in browsers, like support for bare module specifiers. That is, you should be able to write code like `import {foldl} from 'lodash';`. Work is underway to support this in the browser without requiring multiple round trips to the server to guess where 'lodash' should be loaded from: https://github.com/domenic/import-maps https://github.com/domenic/import-maps

snek 8y ago

The issue is that transpilers didn't implement correct ESM (both ts and babel have opt in flags to enable more-correct-mode, but its still not 100%). they implemented the syntax but forgot about the actual semantics like dependency graph verification and such. Node is an actual implementation of js and so we must perform these tasks, even while transpilers don't.

efdee 8y ago
Honest question: Does anybody actually care that it doesn't?
- snek 8y ago
  I don't think its as much a matter of people caring or not as it is that node is implementing ecma262 esm, not babel esm or typescript esm, etc.
  - nobleach 8y ago
    What happens if people seem to prefer the babel-esm semantics? I'm not saying that babel's semantics ARE better, but what if developers prefer them?
    - snek 8y ago
      then they can continue using them, and not use the real esm semantics? i don't think anything would change for them.
- rictic 8y ago
  It matters. Projects that don't support IE ≤11 could ship ES Modules to the browser today. However, you can't ship most code that's written as "es modules" because this code is typically written for a transpiler rather than a real runtime modules environment. Some of this is a limitation in browsers, like support for bare module specifiers. That is, you should be able to write code like `import {foldl} from 'lodash';`. Work is underway to support this in the browser without requiring multiple round trips to the server to guess where 'lodash' should be loaded from: https://github.com/domenic/import-maps https://github.com/domenic/import-maps