TC39 Module Harmony on 2022-06-29

22:02	<Kris Kowal>	nicolo-ribaudo: can you confirm a suspicion for me? Am I right that 262 does not specify a module map at all? All module map behavior is deferred to host hooks?
22:03	<Kris Kowal>	Follow-up, where does the web anchor its module map? Realm, Agent, Agent Cluster?
22:06	<nicolo-ribaudo>	nicolo-ribaudo: can you confirm a suspicion for me? Am I right that 262 does not specify a module map at all? All module map behavior is deferred to host hooks? Yes, you are right
22:06	<Kris Kowal>	I’ve been talking to Caridy Patiño about carving the leanest subset possible out of the compartments proposal. One of the motivating reasons is that we are less likely to encounter friction with hosts if we’re not the first proposal to introduce a distinction between import specifier and referrer specifier (where there’s currently just module specifier and that means import specifier), and not confine hosts to implement module maps in any particular way.
22:06	<nicolo-ribaudo>	Follow-up, where does the web anchor its module map? Realm, Agent, Agent Cluster? I don't know yet, I might have an answer next week because I still need to finish reading that part of the spec 😬 unless you find it earlier
22:07	<Kris Kowal>	Thanks. I would be delighted to benefit from your exploration!
22:07	<Kris Kowal>	Toward that end, trying to glean as much as I can from the spec text you landed in blocks.
22:08	<Kris Kowal>	In any case, I think I’m getting closer to isolating the major axes of design tension so we can have a productive conversation at the call next Wednesday.
22:09	<nicolo-ribaudo>	Awesome! I also still have to fix some other things in module blocks, since my changes were in the good direction but I'm not satisfied yet
22:09	<nicolo-ribaudo>	And that involves learning more about how html handles modules
22:09	<Kris Kowal>	One of those axes is whether to reify ModuleInstance vs ModuleLoader (by whatever names). ModuleSource (by whatever name) exists in either version.
22:14	<Kris Kowal>	Along that axes, the dominant design tensions appear to be: With ModuleInstance, some responsibility passes to the host hooks to maintain idempotence, whereas ModuleLoader can encourage but not enforce idempotence. There’s no viable proposal that fully enforces that invariant, as that would be antithetical to some of the motivating cases. With ModuleLoader (by whatever name), carry a virtualized module map. That does not need to be an imposition on the current host-defined module map, and it should be possible to virtualize the web.
22:15	<Kris Kowal>	It might be possible to sweep referrer under the rug, but I doubt it.
22:15	<nicolo-ribaudo>	So actually, I would prefer to move as much as possible from host hooks to 262
22:15	<nicolo-ribaudo>	And my recent updates to the module blocks proposal go in that direction
22:15	<Kris Kowal>	That is, there might be a way for user virtualized hosts to have everything they need just using ModuleInstances and using either expandos or WeakMap to associate them with their referrers.
22:16	<Kris Kowal>	Well, that’s neat. If hosts are on-board with that, then that takes some tension away from the design.
22:18	<Kris Kowal>	I will look to see how you are consolidating host hooks into 262. If that’s the direction, then my intuition that module loaders are a thing that can be factored out of some other per-realm behavior, might not be entirely wrong.
22:19	<Kris Kowal>	Are you going so far as to pull module maps into the spec?
22:26	<Kris Kowal>	So, assuming, `new ModuleInstance(source: ModuleSource, referrer: string, options: {loadHook, importHook, importMeta})`, `ImportHook(specifier, referrer) => Promise<ModuleInstance>`, I think there’s a proposal that is equally capable of satisfying the motivating cases of `Compartments`, probably more satisfying for hot-module-replacement and WASM, and possibly corresponds more closely to your work on module blocks.