4 ms·

Dynamic import() is asynchronous. I have things that are not asynchronous. To rewrite to be asynchronous gets me exactly nothing. In work that is asynchronous

Dynamic import() is asynchronous. I have things that are not asynchronous. To rewrite to be asynchronous gets me exactly nothing. In work that is asynchronous, I use import(). It's fine. Also, it gives me nothing but, since that particular thing is already async, why not? This is a terrible, badly thought out thing that was done by ECMA that harms a ton of developers and that would have been entirely saved if somebody had asked me. I would have said, add importSync() and there will be literally no problems ever again.

recursive 2y ago
No code or event handlers could run while importSync is resolving. I think including it would have been a mistake. The only other thing that's remotely similar are alert() and inputBox(). IMO it would be a pandora's box of unending problems. A function doing a synchronous dynamic import creates a bad user experience. It's also a pretty rare circumstance in my experience. Dynamic imports are relatively uncommon to begin with. Having one that must be inside a non-async function is unheard of for me. If you had your way, I think the net result would have been worse.
- maple3142 2y ago
  I don't think it is a big problem given functions like fs.readFileSync already exists. It doesn't have to be a JS standard but be a server-side JS runtime specific function, which can be used when hacks are needed.
  - recursive 2y ago
    Node could just do that. `fs` isn't an ES spec, and nor does `importSync` need to be. The blame can't be placed on ESM for this.
    - tqwhite 2y ago
      I agree. The blame belongs to the NodeJS steering committee. It's their failure and it's a big one. The only excuse is that ESM happened during the big Deno Node wars when the community was split, everyone was mad and, apparently making dumb decisions. I read that a new version of NodeJS has revised require() to bring in ESM modules. That's good enough. (I would prefer importSync() for clarity.)
tqwhite 2y ago
I understand that importSync() is blocking. That is fine when it is fine. I am a programmer. I can make sync vs async decisions.
- recursive 2y ago
  The browsers would never implement it.
  - efilife 2y ago
    This is not a talk about browsers, hence the readFileSync examples
    - recursive 2y ago
      The reason we got here in the first place was trying to standardize the language and its module loading. If you come up with a solution that doesn't work in browsers, we're back to the same thing. Instead of the `require()` polyfill, we'd need the `importSync` polyfill.
  - tqwhite 2y ago
    Nor do they have require(). That’s not the point.
    - recursive 2y ago
      And the fact that require() is non-standard is why we're talking about ESM now. Node can cook up another non-standard package loading thing whenever they want. It just won't be ESM. And if you don't care what browsers do, then we're not talking about ESM.

recursive 2y ago

No code or event handlers could run while importSync is resolving. I think including it would have been a mistake. The only other thing that's remotely similar are alert() and inputBox(). IMO it would be a pandora's box of unending problems. A function doing a synchronous dynamic import creates a bad user experience. It's also a pretty rare circumstance in my experience. Dynamic imports are relatively uncommon to begin with. Having one that must be inside a non-async function is unheard of for me. If you had your way, I think the net result would have been worse.

maple3142 2y ago
I don't think it is a big problem given functions like fs.readFileSync already exists. It doesn't have to be a JS standard but be a server-side JS runtime specific function, which can be used when hacks are needed.
- recursive 2y ago
  Node could just do that. `fs` isn't an ES spec, and nor does `importSync` need to be. The blame can't be placed on ESM for this.
  - tqwhite 2y ago
    I agree. The blame belongs to the NodeJS steering committee. It's their failure and it's a big one. The only excuse is that ESM happened during the big Deno Node wars when the community was split, everyone was mad and, apparently making dumb decisions. I read that a new version of NodeJS has revised require() to bring in ESM modules. That's good enough. (I would prefer importSync() for clarity.)

tqwhite 2y ago

I understand that importSync() is blocking. That is fine when it is fine. I am a programmer. I can make sync vs async decisions.

recursive 2y ago
The browsers would never implement it.
- efilife 2y ago
  This is not a talk about browsers, hence the readFileSync examples
  - recursive 2y ago
    The reason we got here in the first place was trying to standardize the language and its module loading. If you come up with a solution that doesn't work in browsers, we're back to the same thing. Instead of the `require()` polyfill, we'd need the `importSync` polyfill.
- tqwhite 2y ago
  Nor do they have require(). That’s not the point.
  - recursive 2y ago
    And the fact that require() is non-standard is why we're talking about ESM now. Node can cook up another non-standard package loading thing whenever they want. It just won't be ESM. And if you don't care what browsers do, then we're not talking about ESM.