concern about a module graph per realm for the web

[caridy]

@domenic raised this concern during a conversation today. From what I gathered, the main issue will be to have more than one module graph per window. He think this is problematic due to how intertwine these two concepts are. Also mentioned memory, and allocation of multiple instances of the same module source as another potential issue.

From the proposal perspective, the reason to not reuse the module graph from the incubator realm is mostly because 2 reasons:

• virtualization/integrity: if your dependencies are running outside the realm, using a different global object, you can't consider the realm an integrity boundary.
• identity continuity: anything that you import uses the same intrinsics.

Up to this point, reusing module instances from other realms was only possible via the compartments API (another proposal).

[littledan]

Modules close over a global object. Our two options for modules and Realms is:

1. Choose a simple default, of using disjoint module graphs
2. Provide some more advanced API to provide the global object when importing a module

This proposal starts with 1, and compartments may provide 2. I think it's appropriate for us to start with a limited scope here.

I'm having trouble understanding the concern about "intertwine"--closing over a global object (i.e. Realm) is just how modules work. It's true that loading modules in Realms will take memory; it also takes memory to load modules in iframes.

@domenic could you clarify what you mean here? These feel like tradeoffs that JS developers can make, not red lines affecting the proposal's viability.

[domenic]

Sure. In web specs and implementations, module maps are tied to WindowOrWorkerGlobalScopes and their associated memory caches/HTTP caches/etc. So you can't introduce a disjoint module map; like other things where realms delegates to their "parent" web global, you need to delegate to the parent web global's module map.

[littledan]

The change I proposed was that HTML would maintain a module map per Realm. What is the reason that it can't be done?

[domenic]

I must have missed that. I was told that the idea was to delegate to the parent realm for important host integration points like URL, HTTPS state, and module map. That is a requirement to avoid complicating the spec and implementation.

[littledan]

The idea is to delegate to the parent realm for basically everything but the module map. It's true that this would consist of spec and implementation changes. Why is it a requirement?

[littledan]

What if we left Realm.prototype.import() for a follow-on proposal, so modules are simply unusable within Realms? Would that satisfy your concerns here?

[domenic]

I'd rather pursue the ideas discussed in #262 (comment), which don't require creating a new type of realm which behaves differently from existing ones in module map behavior.

[frehner]

a hopefully related question I had regarding this is - if each realm had their own module graph, would that also mean that each realm would have to have their own defined import map as well? or what would the relationship be regarding realms and import maps?

[littledan]

Realms get a new copy of modules which closes over the global object, but module resolution is unchanged. All Realms share the same module resolution algorithm from the host. On the web, in the current integration proposal, they would all reference the same import map of the page. Configurability of module resolution is under discussion in the context of the Compartments proposal.

[leobalter]

I would like to reiterate over this issue.

With the new proposed Callable Boundaries API, we still remain with our goals for the constructed Realms to have a new set of intrinsics in a separate Global object.

The non-primitive access is not possible anymore, but I believe if we do share a module graph, evaluated modules might still leak existing global values (not limited to intrinsics) cross realms, not preventing the identity discontinuity problems.

A separate module graph is important so each module is evaluated within the Realm importing it.

@domenic I wonder if you would now consider this option as your feedback here is really important to advance this proposal.