* [Terminology](#terminology) - what we mean by "_term_" in this document

* [Bootstrapping core](#bootstrapping-core) - how to enable Polyscript in your page

<details>

<summary><strong>Interpreter</strong></summary>

Also commonly referred as *runtime* or *engine*, we consider an **interpreter** any "_piece of software_" able to parse, understand, and ultimately execute, a *Programming Language* through this project.

<details>

<summary><strong>Target</strong></summary>

When it comes to *strings* or *attributes*, we consider the **target** any valid element's *id* on the page or, in most cases, any valid *CSS* selector.

<details>

<summary><strong>Env</strong></summary>

ℹ️ - This is an **advanced feature** that is worth describing but usually it is not needed for most common use cases.

<details>

<summary><strong>document.currentScript</strong></summary>

No matter the interpreter of choice, if there is any way to reach the `document` from such interpreter, its `currentScript` will point at the exact/very-same script that is currently executing the code, even if its `async` attribute is used, mimicking what the standard [document.currentScript](https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript) offers already, and in an unobtrusive way for the rest of the page, as this property only exists for *synchronous* and blocking scripts that are running, hence never interfering with this *core* logic or vice-versa.

<details>

<summary><strong>XWorker</strong></summary>

With or without access to the `document`, every (*non experimental*) interpreter will have defined, either at the global level or after an import (i.e.`from polyscript import XWorker` in *Python* case), a reference to the `XWorker` "_class_" (it's just a *function*!), which goal is to enable off-loading heavy operations on a worker, without blocking the main / UI thread (the current page) and allowing such worker to even reach the `document` or anything else available on the very same main / UI thread.