25 ms·

> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of th

> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...

lucacasonato 5y ago
No no, this is about things like importing WASM through the `import` keyword, or referencing assets statically through syntax: Asset References: https://github.com/tc39/proposal-asset-references https://github.com/tc39/proposal-asset-references Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection https://github.com/tc39/proposal-import-reflection
nicoburns 5y ago
I wouldn't worry about that. Node is moving to ECMAScript modules.
- akyoan 5y ago
  Node is not "moving to ESM", they don't even plan to deprecate CJS. They will continue to support both for the foreseeable future. Their docs still use `require` in a lot of places even though ESM has been enabled on stable releases for almost 2 years.
  - ecares 5y ago
    PRs on doc are always appreciated.
  - lloydatkinson 5y ago
    I heard there was a movement internally for a while to block adoption of ES modules because the core team members "didn't like ES modules" (again, what I saw tweeted a long time ago and don't remember the source). So that certainly can't be helping adoption of it. This is one of the reasons Deno is superior - it makes use of language features not a badly designed module format.
ptx 5y ago
What are the problems with commonjs/amd/umd? I'm only vaguely familiar with the JS ecosystem. Is it mainly that the dependencies can't be statically analyzed?
- forty 5y ago
  Yeah I have been happy with require/commonjs for the last ~10 years, I'm not sure why suddenly it seems to be a problem. The main problem to me is this push to this ESM thing, which I don't know what it brings to me. I understand it's a frontend thing, so I'm not sure why nodejs end npm need to be impacted.
  - lucacasonato 5y ago
    ESM is not a frontend thing. ESM is the standardized way of doing module imports in JS. It has a lot of benefits for server side developers too: - It has language syntax for importing and exporting instead of relying on an implicit global. - It is asynchronous, allowing for top level await. - It is reliably statically analyzable. - Because it is asynchronous, module asset loading can happen in parallel which can mean a significant startup speedup for larger projects. - It is standardized, so it behaves the same across Node, Deno, the web, bundlers, linters, and other tooling.
    - forty 5y ago
      I'm not convinced :) Admittedly the largest project I'm working on is mostly in TS now, and I probably get most of the benefits of the import syntax even if require is used under the hood (including linters, which I think worked even before we switched to typescript).
    - lloydatkinson 5y ago
      Exactly this and I'm a little disappointed, though not surprised that the response was "well it works for me so what's wrong with it? it's only for frontend". It's actually part of the language. You also forgot another super important point: - It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flux-inverter tower of cards collapses when a commonjs module somehow leaks in from node_modules?

lucacasonato 5y ago

No no, this is about things like importing WASM through the `import` keyword, or referencing assets statically through syntax: Asset References: https://github.com/tc39/proposal-asset-references https://github.com/tc39/proposal-asset-references Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection https://github.com/tc39/proposal-import-reflection

nicoburns 5y ago

I wouldn't worry about that. Node is moving to ECMAScript modules.

akyoan 5y ago
Node is not "moving to ESM", they don't even plan to deprecate CJS. They will continue to support both for the foreseeable future. Their docs still use `require` in a lot of places even though ESM has been enabled on stable releases for almost 2 years.
- ecares 5y ago
  PRs on doc are always appreciated.
- lloydatkinson 5y ago
  I heard there was a movement internally for a while to block adoption of ES modules because the core team members "didn't like ES modules" (again, what I saw tweeted a long time ago and don't remember the source). So that certainly can't be helping adoption of it. This is one of the reasons Deno is superior - it makes use of language features not a badly designed module format.

ptx 5y ago

What are the problems with commonjs/amd/umd? I'm only vaguely familiar with the JS ecosystem. Is it mainly that the dependencies can't be statically analyzed?

forty 5y ago
Yeah I have been happy with require/commonjs for the last ~10 years, I'm not sure why suddenly it seems to be a problem. The main problem to me is this push to this ESM thing, which I don't know what it brings to me. I understand it's a frontend thing, so I'm not sure why nodejs end npm need to be impacted.
- lucacasonato 5y ago
  ESM is not a frontend thing. ESM is the standardized way of doing module imports in JS. It has a lot of benefits for server side developers too: - It has language syntax for importing and exporting instead of relying on an implicit global. - It is asynchronous, allowing for top level await. - It is reliably statically analyzable. - Because it is asynchronous, module asset loading can happen in parallel which can mean a significant startup speedup for larger projects. - It is standardized, so it behaves the same across Node, Deno, the web, bundlers, linters, and other tooling.
  - forty 5y ago
    I'm not convinced :) Admittedly the largest project I'm working on is mostly in TS now, and I probably get most of the benefits of the import syntax even if require is used under the hood (including linters, which I think worked even before we switched to typescript).
  - lloydatkinson 5y ago
    Exactly this and I'm a little disappointed, though not surprised that the response was "well it works for me so what's wrong with it? it's only for frontend". It's actually part of the language. You also forgot another super important point: - It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flux-inverter tower of cards collapses when a commonjs module somehow leaks in from node_modules?