| 12:09 | <Jack Works> | I presented the latest updates of compartment proposal and having some question from the JSCIG |
| 12:11 | <Jack Works> | Why "loader" will provides the virtualization of the global object? They looks overlap with ShadowRealm |
| 12:13 | <Jack Works> | Actually I'm also curious about this problem. If I have Compartment proposal, ShadowRealm is useless to me. It is hard to use and not provide more abilities than compartment (when the intrinsic are froze). |
| 17:34 | <Kris Kowal> | There is indeed some overlap, and some of that falls out naturally from the nesting of the dolls: Every realm is among other things a loader. And there will be some subtlety to whether a Realm or a Compartment is a good fit for a particular use case. |
| 17:35 | <Kris Kowal> | One big difference is that a Loader-with-a-new-global comes with only three fresh intrinsics: new evaluators bound to the compartment. |
| 17:36 | <Kris Kowal> | Consequently, module instances can be shared between loaders, whereas module instances cannot be shared between realms. |
| 17:37 | <Kris Kowal> | Static module records can of course be shared in both cases. |
| 17:40 | <Kris Kowal> | HMR and test watchers can be done with either, but for these cases I think Compartment-with-shared-global is much lighter and can hand off state more easily. |
| 17:40 | <Kris Kowal> | Deferred execution can not be done by a Realm. That’s the case Guy and Luca brought to our last plenary. |
| 17:41 | <Kris Kowal> | This is a good question, though, and we need to document an answer in the Compartment design rationale. |
| 17:41 | <legendecas> | Is deferred execution related to a distinct global object? |
| 17:42 | <Kris Kowal> | And that is in fact issue #1 https://github.com/tc39/proposal-compartments/issues/1 |
| 17:43 | <Kris Kowal> | No, you can defer execution with a shared global. That’s orthogonal. |
| 17:44 | <Kris Kowal> | One motivating case for detached global is our Hardened JavaScript isolation mechanism. That’s at least my primary motivation as a champion. |
| 17:46 | <Kris Kowal> | We can shim most of what we need with a very minimal carve-out for a detached global. Without that carve-out, the hardened JavaScript shim (ses) would continue to need to fully emulate the loader aspect. |
| 17:46 | <legendecas> | Thanks for the reply. I'm interested in the details about how ShadowRealm could work with Compartment/Loaders |
| 17:47 | <legendecas> | Wondering if that could be done with composing ShadowRealm with Compartments? |
| 17:48 | <Kris Kowal> | So, the way the spec text is likely to go for compartments/loaders begins with a refactoring to decouple the existing Loader from the existing Realm in the spec, such that the Realm is a Loader, but not necessarily the only loader in that realm. |
| 17:50 | <Kris Kowal> | So, as a consequence of the factoring, ShadowRealm and Compartment can be used in tandem. But, I suspect you have something else in mind. |
| 17:51 | <legendecas> | Well, the question about why we need a "detached global" just come up to my mind when I find that the proposal is going to be renamed as Loader, which sounds to me has nothing to do with globals at the first place |
| 17:52 | <Kris Kowal> | One interesting motivating use case that would rely on both ShadowRealm and Compartment would be creating a Compartment inside a ShadowRealm with different hooks. That is to say, constructing a ShadowRealm and then bootstrapping a non-host module-loader. |
| 17:52 | <Kris Kowal> | That’s a good argument to continue calling it Compartment, but the substance of the proposal would be identical regardless. |
| 17:52 | <legendecas> | One interesting motivating use case that would rely on both ShadowRealm and Compartment would be creating a Compartment inside a ShadowRealm with different hooks. That is to say, constructing a ShadowRealm and then bootstrapping a non-host module-loader. |
| 17:53 | <Kris Kowal> | As a champion, I’m eager to deëmphasize the detached global feature, but not remove it. |
| 17:54 | <Kris Kowal> | Because there are so many cases where a Compartment with a shared global is useful, I imagine that will be the primary usage. |
| 17:55 | <legendecas> | I would be happy to see the works going on to elaborate the design rationale in the repo on this :D |
| 17:56 | <Kris Kowal> | A Compartment with a detached global is necessary for other single-realm isolation motivating cases. |
| 17:56 | <Kris Kowal> | Yes, for sure. |