https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95...
Promises, afaik, are always asynchronous. Maybe the spec changed (I'd welcome it for sure) but last I read it, resolve or rejection handlers must be called in the next tick. Even if something can be executed immediately, it'll still wait till next tick. This obviously means there's always a wait associated with promises, hence they are always asynchronous.
I wish this article would go into more detail on what the edge cases are with the unambiguous module syntax – I thought that was an unusually elegant solution in this community.
In this scenario, I believe the idea is that the module could be loaded synchronously, but the Promise would still be resolved or rejected in the next tick.
Right now, Node uses require(). What he means here is that while this does return a Promise, the underlying loading of the module doesn't have to be asynchronous, you could just do something like this:
function import(module) {
return Promise.resolve(require(module));
}
Which would fill the requirement of returning a Promise, but would actually load the module using the normal synchronous means.> I thought that was an unusually elegant solution in this community.
The biggest issue with unambiguous module syntax is that, since you have to parse modules before finishing the resolution, it could drastically lengthen startup time.
Regarding parsing modules – that's a fair point but surely this has to be done anyway? For ESMs you have to parse them to build the binding map, and for CJS you have to parse to evaluate; either way the modules get parsed at some point so why would this in any way be an additional overhead?
It does seem like it'll be a while before we can use this in an Node.js LTS.