| 08:36 | <yulia> | Thanks Rob Palmer for the input, very good points raised. My personal take on this perspective would be to ensure we have lazy execution and sync execution as a possibility of the "epiche" (in the spirit of continued mutation of the word). I completely get that these CJS -> ESM scenarios are causing friction for adoption, although a concern here is that this is a Node.js-specific issue that even with a spec unlock won't guarantee progress. Unfortunately Node.js is now caught up in a bind with its own loader system causing asynchronous loading requirements, although there are people actively working on making hooks sync by moving them off thread. Funding on the Node.js side may well speed things up there as well. On the ECMA-262 side, I could imagine a follow-up or new iteration of Yulia's proposal that tackles lazy execution and sync execution to fit into this story and I'd be more than happy to be involved in discussions here. From my perspective I don't see any frictions or concerns regarding the overall picture, short of more features just being more complexity, but I don't personally see an issue with adding complexity to the module system since it also means more control over performance and loading in the hands of users. |
| 08:37 | <yulia> | This would require loosening early error restrictions, maybe only for modules |
| 10:53 | <Rob Palmer> |
Please could you expand on what this means, Yulia |
| 10:55 | <yulia> |
|
| 10:56 | <yulia> | the idea is to make the only observable difference be time |
| 11:02 | <Rob Palmer> | I can understand that the host-provided loader could differ. What about virtualized environments? I was assuming a user-hosted virtualized module graph could/would be as identical as possible - and therefore if sync loading were possible, that would be achievable in a virtualized environment running in a browser. |
| 11:16 | <yulia> | yes, if i understand things correctly, virtualized environments would allow this. Maybe i don't understand where the confusion is? |
| 11:23 | <Rob Palmer> | IIUC it sounds like Node could offer sync loading, browsers would not, and virtualized environments on both could |
| 13:15 | <nicolo-ribaudo> | Sync loading would also solve the concern that some delegates have with the stdlib modules that some delegates have, that they wouldn't be synchronously available in scripts |
| 13:18 | <yulia> | just so we are clear... there isn't a disagreement here? |
| 13:24 | <nicolo-ribaudo> | ^ temperature check 😉 ➕, 🟰, and ➖ |
| 13:43 | <Rob Palmer> | just so we are clear... there isn't a disagreement here? |
| 13:44 | <littledan> | Moddable has also brought up sync loading as an important concern for them |
| 13:44 | <littledan> | Promises often have too much overhead |
| 13:44 | <littledan> | At the same time, TC39 has so far come down hard on the side of async loading |
| 13:44 | <yulia> | yes -- I think my goal would be to provide a way of restricting modules to a subset where differences in loading are undetectable. |
| 13:44 | <littledan> | There was a big debate at the point of introducing dynamic import, for example. |
| 13:44 | <yulia> | so, they can be shared across different loading strategies and work roughly the same way |
| 13:45 | <yulia> | There was a big debate at the point of introducing dynamic import, for example. |
| 13:46 | <littledan> | (TLA would be handled by running the async subgraph eagerly, and only being lazy about the stuff on top of that) |
| 13:46 | <littledan> | JS doesn't have much of a pure subset--just function declarations basically |
| 13:46 | <littledan> | Deferred module evaluation, in how I pictured it, would be observable but well-defined |
| 13:46 | <yulia> | My view is: we have a low level utility for customizing loading however necessary. In addition, we have a "programmer mental model assisting" way of writing moduels -- where the module is written in a way that it doesn't expose some behaviors. I think we are all discussing the same thing: no TLA. In addition, no modification of globals in my view |
| 13:47 | <yulia> | yep, there is an observable aspect to it |
| 13:47 | <littledan> | yes... i recall this one and reading through it. Dynamic import was initially introduced to allow something like cjs loading iirc |
| 13:47 | <yulia> | ideally, its "just" timing. in practice -- early errors, and impacts on the module itself would be observable |
| 13:48 | <littledan> | yes -- I think my goal would be to provide a way of restricting modules to a subset where differences in loading are undetectable. |
| 13:48 | <yulia> | What do you mean by this comment on motivation? I thought code splitting was always part of the goal. |
| 13:49 | <littledan> | Yeah no disagreement that something analogous to require was one of the goals |
| 13:56 | <Jack Works> | yes... i recall this one and reading through it. Dynamic import was initially introduced to allow something like cjs loading iirc |