Official name bikeshed

[syg]

With Realms at Stage 3, let's have an earnest bikeshedding discussion on the name "Realm". We've talked about renaming it many times in the past but AFAICT never had the earnest discussion. The shape of the current proposal has deviated sufficiently from long-standing uses of "Realm" in ecma262 and HTML that a different name seems more appropriate.

At the July TC39, we have consensus that the major JS vendors (browsers + node) will hold off shipping (but not implementing!) until we've bikeshedded.

[ljharb]

Of the ones i've heard tossed around so far, "CallableBoundary" seems the most apt.

[Jack-Works]

Isolate 🤣

[syg]

Isolate

Hard pass. :)

[guybedford]

I wonder if Membrane makes sense?

[syg]

I wonder if Membrane makes sense?

Also no IMO, because it is not really a membrane in the technical sense. So far I also think CallableBoundary is the most accurate.

[mhofman]

CallableBoundary is a bit of a mouthful for a user visible API. It also doesn't capture the fact you get a whole new set of intrinsics and that module instances are not shared.

Context like Isolate is a very overloaded term. I unfortunately don't have any better ideas that come to mind.

[ljharb]

a bit of a mouthful for a user visible API

SharedArrayBuffer and FinalizationRegistry would like to have a word with you :-p

[kriskowal]

Riffing: Intrinsics (new Intrinsics()), ParallelRealm, ThroughTheLookingGlass (LookingGlass, Glass, certainly not Window).

I still like Realm. It fits the bill and the probability of another first-class API appearing that would be a stronger contender for the name is unlikely. It’s far more likely that we’d parameterize the existing Realm constructor for variations on the theme. That there are multiple internal names fit the bill doesn’t condemn the public name, and some of those internal things might be factored differently in the future anyway, as we decompose the notion of a worker/page/agent which consists of a realm (for intrinsics) which consists of a compartment (for module graphs).

[leobalter]

From all the previous name bikesheds I've seen about Realms, CallableBoundary doesn't seen bad.

If we want something even more accurate I'd say CallableBoundaryRealm would be better, but only in this aspect. CallableBoundary translates well what this API does.

I'm in favor of this name because it's also very specific to this API and this is very helpful for users to search and find related documentation without noise.

The closest concept name I'd think would be an Acrylic Glove Box, and I hoped for it to have a specific single name, maybe in German.

I'd like to register one of the concerns for this name is the confusion of other things sharing the name in the HTML spec reality. This creates confusion there and implementation. @syg might correct me if I said anything wrong. IMO, this is a compelling argument and I'm fine with a distinct name.

I'll have a PR-draft open to make sure I capture all the parts that would need to be renamed. Maybe seeing it from a rendered spec would make it easier to digest.

[kriskowal]

The closest concept name I'd think would be an Acrylic Glove Box, and I hoped for it to have a specific single name, maybe in German.

You win this round @leobalter. Do we camel case with a hump for every composite of a compound German word likeAcrylHandSchuhFach?

[Jack-Works]

IsolateRealm?

[ljharb]

I still think using "isolate" as a noun, instead of a verb, is very weird.

[Jack-Works]

I still think using "isolate" as a noun, instead of a verb, is very weird.

Then IsolatedRealm

[leobalter]

I believe Isolated or any derivation won't be successful as some delegates don't see this API as full isolation set.

The problem for the naming here is that every name we pick will have objections against.

I'm not kidding that we need to pick the least offensive name.

[caridy]

The prior art is "Context", which is available in node, jscore/ios and v8/android. Creating a new Context(), or new CallableContext() reads well IMO.

[ljharb]

"Context" is way too overloaded a term (think scope) - i'm pretty strongly opposed to that.

[Jamesernator]

My feeling is that names like CallableBoundary doesn't desribe the core functionality of a new "Realm" which is a set of intrinsics/builtin/global. The callable boundary aspect is more of an interface.

Perhaps something like GlobalScope/GlobalEnvironment/FreshBuiltins, admittedly I like none of these extra words like Scope/Environment/Fresh but perhaps there's a more fitting word.

This kind of naming makes more sense with the methods, e.g. globalEnvironment.evaluate(script) can be read as evaluate the script script in the global environment globalEnvironment. (Names like CallableBoundary don't make as much sense, e.g. you wouldn't evaluate a script IN a "callable boundary", the boundary is only the thing that separates the global scopes).

[ljharb]

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

[Jamesernator]

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

But that's exactly what it does, it's just that you can't interact with it except through the evaluate/import methods. The fact the global scope isn't directly accessible doesn't mean it isn't there. And in fact, with a membrane you can almost directly interact with it as if they were just another set of intrinsics.

[Jack-Works]

Maybe Realm is good enough

[ljharb]

Sure, but this isn’t a membrane, and this thing isn’t actually the thing you’re interacting with - it’s still just a screen even if i can use it to remotely view and interact with another place :-)

[erights]

I agree with @Jack-Works that just Realm is fine. It's not like the current exposed realms of iframes or vm.createContext are already widely known as realms, so I don't think calling this new thing Realm would be confusing.

[ljharb]

@erights https://github.com/search?q=cross-realm seems relatively widely used as a justification for use of Array.isArray, among other things.

[caridy]

CallableRealm?

[leobalter]

@caridy please no! Because the constructor throws a TypeError if new target is undefined makes me not want to call it CallableRealm.

[bathos]

Since it doesn't provide an actual global object/globalThis, or a container of intrinsics/builtins/etc, then the name shouldn't imply that.

Agreed, please don't call it "intrinsics" given some of us are still hopeful that a future proposal will provide what we were hoping this one would (fresh intrinsics).

[victornpb]

Here’s some alternative names, in no particular order:

• new Container()
• new Bubble()
• new Land()
• new Arena()
• new Canister()
• new Crate()
• new Jar()
• new Bowl()
• new Capsule()
• new Vase()

I particularly like Realm but something like Land seems pretty close to the original but being different at the same time.

[mhofman]

I actually like Bubble. It's a sphere with a boundary isolating the inside and outside. And lexically it fits nicely between Agent and Compartment.

[erights]

Yay Bubble !

Btw, the thing the spec calls "Agent" I hope we never expose in an API with the name "Agent". This would be the worst terminology choice of all. So I discount the lexical argument for Bubble ;) . I like it anyway.

[erights]

Here’s some alternative names, in no particular order:

• new Container()

Too similar to Compartment. With both in the language, will people naturally remember which is which? Is it more natural that multiple containers fit in a compartment or that multiple compartments fit into a container?

• new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

• new Land()

I just don't like it. Since I don't know why I don't, I cannot know I would not get used to it. But I don't like it.

• new Arena()

Interesting. Would like to hear more.

• new Canister()

Same reaction as with Container. People won't remember which is the canister and which the compartment unless there's a least a good metaphor to explain which goes into which.

• new Crate()

Fatal Rust conflict

• new Jar()

Fatal Java conflict

• new Bowl()

Interesting. Would like to hear more.

• new Capsule()

Interesting. Would like to hear more.

• new Vase()

Interesting. Would like to hear more.

[chris-kruining]

just my two cents and it probably is in line with the same pushback as words like container. But here's mine: Box I see this as one of those sorting/storage boxes. the one with where you open a lid and have multiple compartments.

So in that sense I can see the logic of a word like Box when placed in context. but remove the context and it is far from descriptive enough.

Personally I also loooove the Bubble proposal. And I kind of have to say that keeping it as Realm seems fine to me as well.

[chris-kruining]

• new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

Does it have to make sense though? I don't have a concrete example, but my gut tells me that ecma has plenty of structures that break metaphores. And as long as it is intuitive enough that a word like bubble is a no-pass-boundary that contains compartments, it seems good enough to me personally.

[chris-kruining]

oooh this whole bubble and metaphore thing made me think of another term, a bad one to use, but a good metaphore: Cell

A cell is a bubble (cell membrane) that has mechanisms to have very controlled "IO" and contains compartments (organelles)

so I guess Cell & Organelle fits the metaphore well, but I do not think it will be intuitive to use.

[bathos]

Bubble seems pretty sweet:

• it provides a hint about the existence of a boundary
• ... but without suggesting something rigid like process isolation (bubbles aren’t known for like, structural integrity)
• the word is established as frequently metaphoric and is used that way in a variety of contexts
• ... but it doesn’t, AFAIK, currently show up in JS / web platform terminology with other meanings
• ... and it’s colorful/memorable, but not overwrought or precious

[littledan]

I like Bubble a lot! CallableBoundary doesn't make sense to me, since these are places to execute code, not just a boudary. OTOH, a bubble clearly has stuff inside it, so it makes more intuitive sense. Somehow, a Bubble feels bigger (and therefore more appropriate) to me than a Box or Cell (which somehow feel like they would just contain one little thing, whereas a Bubble could encapsulate a bunch of stuff).

Let's aim to have this bikeshed settled by next TC39 meeting.

[littledan]

new Bubble()

Memorably different and enjoyably playful. But does it make any metaphorical sense to have multiple compartments inside each bubble?

I'm not sure if it makes much sense to have multiple compartments inside of any of the things. I'm also not sure that compartment is the right word to use for "a context where a particular module loader is used". TBH "Compartment" wouldn't be a bad name for this proposal, with the current compartment proposal then taking a different name (loader?).

Thinking more about the relationship with compartments, a naming scheme comes to mind:

• Realms could be called ObjectArena
• Compartments could be called ModuleArena

In general, "arena" could mean "a place which has its own stuff of a particular type". Or, we could call these ObjectContainer/ModuleContainer, or even ObjectBubble/ModuleBubble.

[chris-kruining]

I'm not sure if it makes much sense to have multiple compartments inside of any of the things. I'm also not sure that compartment is the right word to use for "a context where a particular module loader is used". TBH "Compartment" wouldn't be a bad name for this proposal, with the current compartment proposal then taking a different name (loader?).

wouldn't this be a namespace? like, in "proper" OO languages this is pretty much what they do, compartmentalization.

[victornpb]

wouldn't this be a namespace? like, in "proper" OO languages this is pretty much what they do, compartmentalization.

I don’t know if the semantic holds down to the details compared to other languages. But I feel like realms is its own thing, so I rather have it have its own name than break expectations.

I'm only familiar with languages that have build time namespacing. This is more like a different "runtime namespace"

[littledan]

I feel like "namespace" already has a different meaning in the JS context, which is things like Math or Intl. TypeScript and WebIDL already use namespace as a keyword for this purpose.

[leobalter]

I don't mind Bubble, it's ok. My only pet peeve for it is the metaphoric relation to the acrylic glove box, in which I'd use to explain how we manipulate things inside and we would eventually use the gloves for some a related metaphor of a membrane system. I don't have a better name, thou.

Again on the pet peeve, Bubble seems like something sealed to the point code injection feels weird. This is a very abstract thinking, thou.

From the other names without immediate objections from @erights, I don't like Arena, Capsule, or Vase. The first gives a different idea of what I have for this API and the others feel like it should be much more sealed if compared to Realms.

From my List:

0.Realm still works fine as a name for me. No implied metaphors but usage of common ES jargon.

1. Bubble seems like a good option as a single word, with a bit of pet peeves.
2. CallableBoundary, I don't love this name but still works as my personal favorite fallback if the names above cannot move forward.

[dgeb]

Atmosphere plays off the "global" metaphor and has many of the same associations as Bubble that work well. But perhaps it's a bit too on the nose.

To be a bit briefer, how about simply Sphere? I feel this works well in many senses, such as a "sphere of interest" or "sphere of control".

[jmshal]

World?

[Jack-Works]

just my two cents and it probably is in line with the same pushback as words like container. But here's mine: Box

Box is conflicting with the Record&Tuple proposal

[rwaldron]

Sandbox

[legendecas]

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

[Jack-Works]

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Yes, a evil code can do while(1) to block the whole thread

[rwaldron]

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Please explain this reply

[littledan]

Something really nice about Bubble is that, unlike Sandbox, it implies a weaker boundary (e.g., it's not Spectre-proof).

[erights]

Sandbox

Sandbox suggests it can be used to run untrusted third-party codes. But to my understanding it's not.

Yes, a evil code can do while(1) to block the whole thread

That's an attack on availability, for which Realms and Compartments indeed provide zero protection, for that reason. However, Realms and Compartments provide strong protection of integrity. Compartments even provide an interesting form of protection of confidentiality.

See https://agoric.com/blog/all/taxonomy-of-security-issues/ and https://ses-demo.agoric.app/demos/challenge/

So Realms and Compartments can and should be used to run untrusted third party code, or not, depending on what threats you're trying to protect against.

[erights]

Something really nice about Bubble is that, unlike Sandbox, it implies a weaker boundary (e.g., it's not Spectre-proof).

Note that Compartments do provide an interesting form of protection of confidentiality, including against Spectre.

See https://agoric.com/blog/all/taxonomy-of-security-issues/ and https://ses-demo.agoric.app/demos/challenge/