19:31
<snek>
joyee: i was trying to understand the different approaches for injecting __esModule on require(esm) on your pr, and reading through it looked like they were all roughly the same performance? i'd like to just use a proxy if possible, but since you went with the wrapper module approach i wanted to double check it wouldn't be bad in some way i haven't seen mentioned.
20:26
<joyee>
The performance difference shows up when you are accessing properties from the returned result, which is relevant for bundled code because they always access it as const loaded = require('esm'); loaded.prop instead of caching const {prop} = require('esm') (in order to preserve live binding)
20:27
<joyee>
https://github.com/nodejs/node/pull/52166#issuecomment-2223998497
20:27
<joyee>
That's the type='access' benchmarks
20:29
<joyee>

For module loading per-se the difference is not too big, the difference lies in property access (or, from the faux-ESM user's POV, every access to named exports from another module)

import { a } from 'esm';

let b;
for (let i = 0; i < 100; ++i) {
  b += a;  // Every access to a goes through the Proxy now
}
20:31
<joyee>
There are some examples of the code emitted by the transpilers, who are what the __esModule thing is for https://github.com/nodejs/node/pull/52166#issuecomment-2145702846
20:34
<joyee>
It would be cool if non-enumerable exports are allowed though, the wrapper module makes __esModule enumerable, which is a bit annoying
20:43
<snek>
That's the type='access' benchmarks
i seeee, ty
20:43
<snek>
yeah i was wishing while writing this that there was a host hook for initializing namespaces. but it would be kind of silly...
20:48
<joyee>
I think when faux-ESM becomes a past, we can just switch to Proxy, until them using the module wrapper would avoid risking making native ESM unattractive (because your faux-ESM user might see funny hot spots of all the Proxied named exports access from your module)
20:49
<joyee>
Or better, having non-enumerable exports, then __esModule is barely visible