Isolated worlds (was Re: Module isolation)

Adam Barth abarth-mozilla at
Sun Jan 10 22:49:50 PST 2010

[Re-sending now that I've subscribed with this address]

I haven't been following this module discussion very closely, but
these recent comments sound related to something we've been playing
around with in WebKit.  We have a mechanism (called an "isolated
world") that lets multiple JavaScript contexts share access to the
same DOM without ever exchanging JavaScript pointers with each other.

1) Each world gets it's own global object, complete with independent,
mutable built-in objects.
2) Each world gets it's own set of (mutable) DOM wrappers.

For those not familiar with the details of browser implementations,
JavaScript DOM objects are usually implemented as wrapper objects
around the "native" object, implemented in C++.  Because each isolated
world gets its own wrappers, the usual one-to-one relation between the
native objects and it's wrapper is replaced with a one-to-many

This trick works nicely because DOM is a language-neutral interface.
Just like you can have Python and JavaScript bindings for the DOM,
isolated worlds essentially lets you have JavaScriptA and JavaScriptB
bindings.  The key invariant is that two worlds never exchange
JavaScript pointers (which you can think of as object-capabilities, if
you like), just like Python and JavaScript would never exchange
pointers if they interacted with the same DOM objects.

I'm not sure this mechanism is directly applicable to future versions
of ECMAScript because we're able to implement it just fine using ES5.
However, it might be an approach worth considering in designing a
module system for ECMAScript.


On Sun, Jan 10, 2010 at 9:38 PM, Brendan Eich <brendan at> wrote:
> On Jan 10, 2010, at 9:30 PM, David-Sarah Hopwood wrote:
>> Brendan Eich wrote:
>>> On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
>>>> From SecureEcmaScript proposal:
>>>> 6. The top level binding of this in an evaled Program is not the
>>>> global object, but rather a frozen root object containing just the
>>>> globals defined in the ES5 spec.
>>> For many current applications, the frozen |this| object is not necessary
>>> or desirable in global code. The essential characteristic of modules,
>>> isolation for each module's "inside" from unimported effects of other
>>> modules, does not necessarily mean no mutation of primordial objects.
>> On the contrary, it does necessarily mean that. If you can mutate
>> primordial objects, then there is no isolation of any module. There
>> may be a reduction in the possibilities for accidental interference
>> between modules, but that should be distinguished from isolation.
> Who said primordial objects are shared between modules? You assume too much
> in assuming your favored conclusion.
> There are three things a module has to deal with to interact with JS in
> browsers:
> 1. The global object and its Object, Date, etc. primordials.
> 2. The |this| binding for "global" code in the module, at the module's top
> level.
> 3. The scope chain tail object, the only object on the scope chain for
> global code in ES1-5.
> These are not necessarily the same at all. The lexical_scope proposal
> eliminates 3 by making the top-level a lexical environment, not an object.
> The |this| binding may or may not refer to the global object. And it's not
> settled whether, in browsers with many global objects (one per
> window/frame/iframe) there is only one global among N>1 modules, or a global
> per module.
> If modules do not use free variables, only what they import, then you're
> wrong that isolation requires freezing. Modules could use their own
> primordials, or none (only library code, possibly better versions of Date,
> etc.). The object and array initialisers and regexp literals would have to
> construct using some "original value" of Object, Array, RegExp. But not
> necessarily a frozen one, if per-module.
> That you conflate frozen primordials with isolation is exactly the kind of
> over-specification through shortest-path evolution of ES5 to which I object.
> It is not going to fly in TC39 among all the browser vendors. We need to
> hear from Apple, Microsoft, and Opera, but I'm already objecting to this
> kind of axiom planting. Let's back up and talk about modules from premises
> forward.
> /be

More information about the es-discuss mailing list