Glue

Most of niso’s web APIs are Rust in the core, reached from JavaScript through host functions generated from WebIDL. Some parts are easier, or only possible, in JavaScript: WebIDL’s argument conversions and wrapper objects, DOMException, the geometry classes, atob, FormData, XMLHttpRequest, FileReader. That JavaScript is the glue.

Where it lives

• bindings/js/glue/*.js: the glue every engine shares (conversions, wrappers, exceptions, scripts, selection, …).
• Sections owned by other crates: each crate that implements an API keeps its glue next to its Rust, and crates/niso-compose puts the sections together in the order crates/niso-compose/sections.txt gives.
• bindings/js/niso_js.c: the C side of the JS binding, which installs the generated host functions and runs the glue in each realm, on any engine through bindings/js/niso_engine.h.

Composition

The same composition step writes niso_runtime.h from header sections, so the C API and the JS glue come from the same set of crates. Some glue is optional: an app that doesn’t use FormData, XMLHttpRequest, DOMParser or FileReader can leave it out with the composing crate’s glue-<section> features (niso-quickjs’s glue-form-data, glue-xhr, glue-dom-parsing, glue-file-reader), which makes its startup a little smaller. Crates and contracts has the rules for who owns what.