Plugins (separate blog post to be extracted)

• MASSIVE help - figma blog on web plugin implementation. Thus commenced my foray into realms and quickjs
  • https://www.figma.com/blog/how-we-built-the-figma-plugin-system/
• evaluated embedded javascript runtime quickjs for plugin isolation
  • https://github.com/justjake/quickjs-emscripten
  • https://dev.to/sebastian_wessel/execute-javascript-in-a-webassembly-quickjs-sandbox-14nn
  • speed considerations, for real-time text editing/incremental parsing, speed is very important.
  • unimplemented and undecided
• possible security concerns and A LOT of implementation and maintenance concerns if we go with shims
  • https://www.figma.com/blog/an-update-on-plugin-security/
  • we have to build our whole layer for communication with plugins that avoid the plugins having any knowledge of our system, and we have to maintain it as well. Will be a lot of work, and i don't think it's worth it.

What is a realm in JavaScript?

Sources:

• http://weizmangal.com/page-what-is-a-realm-in-js/
• https://www.youtube.com/watch?v=l2l_qnEhx3M
• ChatGPT Summarization

A realm is the world/ecosystem in which a JavaScript program lives. It includes different elements that JavaScript programs must have in order to exist within it.

• A globlal execution environment
• A global object (and intrinsic objects)
• Javascript itself

If I want to create a realm, i must provide the above components, for any javascript program to be able to run in it

A global execution environment

In javascript, we have different scopes.

let x = 1;
let innerScope = () => {
  let y = x + 2; // we can access x from the outer scope
};
let z = x + y; // Uncaught ReferenceError: y is not defined

in the above example, we are able to declare a scope called innerScope, in which we can define variables that belong to the scope (i.e. y) and that cannot be accessed outside of the scope.

It is possible as well that this whole javascript program itself is an inner scope within some larger outer scope. maybe it is imported from a different file or something (need to verify if this is a correct example) in which case the file importing it will be a higher-level scope.

If we keep going up and up in scope, we will eventually get to the top-level declaration - the outer-most scope. This is the global execution environment.

In this scope, or global execution environment, we can declare new variables. Based on how we declare new variables in the top-level scope, we can populate new definitions in two different places:

• The "declarative environment"
  • we do this whenever we use keywords such as let, class, module, import, and/or function in the global execution environment to declare stuff
  • things declared this way are stored in the declarative environment (TODO: verify if this is a memory storage location thing, or a conceptual thing)
  • these variables defined using the declarative environment declarations (let, const, class, e.t.c.) are blocked-scoped, and do not become properties of the global object
  • These are not tied to the global object. They don't create a global variable.
    • even though they do not attach to the global object, they are still available to inner scopes (source: chatgpt. verify)
    • the key difference is that they just don't become properties of the global object (like window or globalThis in Node.js)
• The "object environment"
  • we do this whenever we use keywords such as var, function, async function, function*, async function*
  • they create properties on the global object (i.e. window, globalThis, e.t.c.)
  • these change based on if we are in strict mode or if the code is being run as a module.
    • i.e. some of these keywords act as declarative environment declaration keywords in that they don't create a global variable. might be other differences. need to do research.

Key Takeaway: A realm provides the javascript program with its own single global execution environment

A global object

The global object is referenced as window for browsers and global for NodeJS environments; in both, globalThis can also be used.

After having a proper environment in which javascript programs can execute, they also need to be able to perform advanced operations, including but not limited to platform based ones. The global object provides access to built-ins such as different intrinsics, objects, APIs, e.t.c. (whether platform specific or not)

Some non-platform based intrinsic objects exposed by the global object:

• values (e.g. undefined, Infinity, e.t.c.)
• functions (e.g. eval, parseInt, e.t.c.)
• constructores (e.g. Boolean, Date, e.t.c.)
• and others (e.g. JSON, Math, e.t.c.)

Some browser-specific APIs exposed by the global object:

• in the browser, fetch, alert, document, the DOM, e.t.c.

Any platform specific objects and APIs are accessible via the global object along with all intrinsic objects and new properties declared by code.

Javascript itself

The last thing that can be associated with a realm is the JavaScript code that runs within the execution environment of that realm.

Any changes/alternations/updates to the execution environment, the global object or anything that is derived under a realm, is also associated exclusively with that realm.

Realms in "real life"

• in the browser, only one realm exists - that is the top main realm. that is the realm where the web app that the browser loaded lives.
• new realms can be created within a realm containing its own separate and unique set of everything a realm must have - global execution environment, global object providing different intrinsic objects and platform specific APIs, e.t.c.
• Every realm lives inside an agent, and an agent can be the parent of multiple realms.
  • The event loop is an agent for example.

Same origin realms

if two iframe realms are of the same origin (child of the same agent),

• they share a single event loop
• can access each others environment synchronously and freely using contentWindow (i believe this is because they share the same event loop? maybe?)

you can achieve same origin realms using iframe, frame, object, embed and open

Cross-origin realms

if they are of different origins (e.g. the top main realm and a service worker (i.e. web worker) are of different origins)

• they have to do cross origin stuff
• limited communication, but can still communicate with each other using postMessage() asynchronous API

an example in the browser implementation of the ecmascript spec is web workers and service workers they are cross-origin realms to all other realms in the web app, such as the "top" realm or "window",

Each realm has its own unique identity with a unique global object, global execution environment, and each realm has its own set of intrinsic objects and platform based APIs. Primitives, however, are identical across realms (i guess they are shared across realms even though they are defined within realms i think?)

<html>
    <head></head>
    <body>
        <iframe id="some_iframe"></iframe>
    </body>
</html>

window === some_iframe.contentWindow // false
window.fetch === some_iframe.contentWindow.fetch // false
window.Array === some_iframe.contentWindow.Array // false

// Primitives
window.Infinity === some_iframe.contentWindow.Infinity // true