Hacker News Reader

Comment by tqwhite | Hacker News Reader

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.

View on HN

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.

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.

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.

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.)

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

The browsers would never implement it.

This is not a talk about browsers, hence the readFileSync examples

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.

Nor do they have require(). That’s not the point.

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.

Reply on news.ycombinator.com