| 09:55 | <nicolo-ribaudo> | could you have used |
| 09:58 | <littledan> | and double-parsing reasons! |
| 09:58 | <littledan> | (loading performance) |
| 16:51 | <Rob Palmer> | Pete Hunt (one of the original Facebook crew that created React) has created hostile forks of popular npm modules that decided to convert to ESM. They are publishing equivalent CJS versions under the npm scope Here is one example: |
| 16:54 | <Rob Palmer> | As I mentioned in July plenary, ESM is kinda failing to take hold in the ecosystem today. I interpret this "let's stick to the old ways" forking as proof of that. It is not random stubbornness - it is born out of the practicalities of migration. The migration is painful and costly and is causing some folk to invest in going backwards. |
| 17:01 | <Rob Palmer> | The root of this, in my opinion, is a lack of the ability to synchronously load ESM in Node. Deno does not have this problem because it's all async from day 1. Bun is potentially going to avoid this problem too by permitting a mixed-mode loader (support both sync and async). In Bloomberg, our loader does not have this problem for the same reason - it can handle both forms of loading. Whilst we could just say "this is a Node-specific problem due to Node's historical choices", I think the need for sync loading is a more generic and shared need. A further evidence point that I have cited many times is the need for non-viral lazy loading, i.e. conditional loading that can happen inside normal non-async functions. This type of lazy loading is widely used in the pre-ESM ecosystem today by large apps. And we still have no equivalent in ESM. |
| 17:03 | <Rob Palmer> | I'm not sure I'm saying anything particularly novel here. Mostly just pointing out there's more evidence of the problem here, so we are all up to date. |
| 17:25 | <nicolo-ribaudo> | I wonder if we should also try to solve the problem from the Node.js side other than from the TC39 side. In theory Node.js could support require("./an-esm-file-without-TLA.js") regardless of what TC39 says |
| 17:27 | <nicolo-ribaudo> | Ok well, I assume that it isn't a novel idea |
| 17:28 | <littledan> | I think this ESM migration story comes up in more contexts than just Node.js, but sure, part of the solution may be Node-specific. |
| 19:52 | <ljharb> | i don't think it could; it's been pursued before |
| 19:53 | <ljharb> | plus all the "be like browser" contingent would never allow it because it'd move node farther from browser ESM, not closer to it |
| 19:54 | <ljharb> | imo there just won't be a concerted migration until the transition and interop story with the largest language ecosystem in history is smooth |