This page indexes the JavaScript API surface available to guest code running
on Elide. Three layers make up that surface:
The Elide global — runtime metadata plus the serve() entrypoint.
node: modules — Node.js built-in modules, resolvable by import or require, with or without the node: prefix. Some are implemented natively by Elide; the rest resolve through the embedded Node compatibility layer.
elide: modules — Elide-specific synthetic modules. These always require the elide: prefix.
Web / WHATWG + WinterCG globals — standards-based globals installed on globalThis (Fetch, Streams, URL, Encoding, timers, performance, and so on).
Every linked page below documents the real, implemented surface of a single
module or global. Where a feature is partial or deferred, the per-module page
says so. For measured JavaScript, WinterTC, and Node-API results from external
compliance suites, see the Compatibility Matrix.
The Elide global
The Elide global is always present when running JavaScript on Elide. Its
current public surface exposes runtime metadata and the serve() entrypoint.
Member
Type
Description
Elide.version
string (read-only)
Version string of the running copy of Elide.
Elide.debug
boolean (read-only)
Whether this build has debugging features enabled.
Elide.release
boolean (read-only)
Whether this is a release-optimized build.
Elide.buildMode
string (read-only)
Build mode label reported by this binary; for example, dev.
Elide.targetArchitecture
string (read-only)
Target architecture label reported by this binary; for example, x86-64-v3, native, or compatibility.
Elide.serve(options)
(ServeOptions) => ServeHandle
Start an HTTP/HTTPS server. The supplied fetch handler is invoked once per request and returns a Response or Promise.
Elide.serve(options) takes a ServeOptions dictionary — a fetch handler is
required; port, hostname, cert, key, idleTimeoutMs, and
maxBodyBytes are optional. It returns a ServeHandle carrying the resolved
port, the bound hostname, and a close() function. See the WebIDL source
for the full dictionary shapes.
javascript
Elide.version; // → e.g. "1.0.0-beta..."
Elide.debug; // → false in release buildsconst server = Elide.serve({
port: 8080,
fetch(request) {
returnnewResponse("hello from Elide");
},
});
server.port; // → 8080// server.close(); // stop accepting and drain
There is noElide.http, Elide.db, or Elide.createContext — HTTP
serving is Elide.serve (see the Elide Global),
and databases are imported as elide: modules (below).
node: modules
Node built-in modules resolve through import or require, with or without
the node: prefix (e.g. both import os from "node:os" and
require("os") work).
The modules below have dedicated reference pages. Most are implemented natively
by Elide. Some modules are backed by the embedded compatibility layer, and
node:child_process is registered as an Elide shim whose entry points are not
yet implemented — each page notes its specifics.
Elide also implements node:dns and node:dns/promises. Additional Node
module names (e.g. net, tls, http) are recognized by the loader but are
not yet documented as stable.
elide: modules
Elide-specific synthetic modules. These always require the elide: prefix
and are registered lazily — importing one does not pollute the global scope.
All three database drivers are covered on a single page — the
Database API Reference. There is no Elide.db global, no
ORM, and no query builder; each driver executes SQL directly. MongoDB and Redis
are not supported.
Web / WHATWG + WinterCG globals
Standards-based globals installed on globalThis. These follow the WHATWG
specifications and the WinterCG Minimum Common API.
The pages below document shared host-internal primitive layers that back the
guest-visible APIs above. They are not directly visible to guest
JavaScript, but are documented for contributors and for understanding backing
behavior:
Layer
Reference
Crypto primitives (back node:crypto and crypto.subtle)