Rasa in the Browser: One Verified Product

Rasa browser pages execute the same Rasa runtime product used by the Wasm host. The website does not contain a JavaScript interpreter or a second language implementation. It consumes one generated browser product through @rasa/browser.

The Product

Core build tooling produces the source components and the complete Rasa source inventory. The browser product builder turns those inputs into one atomic, inventory-verified distribution:

browser-product.json
browser-product.sha256
api/
runtime/
  capability-jspi/
  pure/
  probes/
source/
package.json

browser-product.json identifies the public API, source inventory, runtime variants, browser requirements, product build identity, and every deployed file's byte length and SHA-256 digest. Validation rejects missing, changed, or undeclared files.

The source Wasm components are build inputs, not parallel deployed runtimes. Each browser variant contains the generated component projection it needs.

Browser Compatibility

The manifest declares requirements for each runtime variant, including WebAssembly, ESM, Web Crypto, JSPI, imported component interfaces, memory shape, and concrete Wasm proposals. Small checked Wasm modules probe proposal support before the large runtime projection is loaded.

Selection follows application needs:

• ordinary source can use the pure variant;
• applications with browser providers require capability-jspi;
• an unsupported browser receives structured compatibility refusals before application source or provider modules execute.

The browser UI may explain those refusals, but it does not choose a weaker runtime or substitute JavaScript execution.

The Public API

The common case is intentionally small:

import { loadProduct } from "@rasa/browser";

const product = await loadProduct("/rasa/browser-product.json");
const session = await product.openSession();
const result = await session.eval("(+ 1 2 3)");

await session.close();
await product.close();

Product owns the verified distribution, selected runtime, providers, and open sessions. Session owns persistent evaluation state. Its eval and load methods return structured runs with values, diagnostics, reports, traces, and phase status.

Inspection and syntax tokens come from the same product:

const artifact = await product.inspect(source, { phases: "all" });
const tokens = product.tokens(source);

Editors render those compiler products. They do not maintain a second Rasa lexer or infer semantic facts from report strings.

Try The Product

This example starts as inert highlighted source. Open it to load the shared CodeMirror editor and verified browser product, then change the collection or the expression and run it again.

(into []
  (map (fn [number]
         {:number number
          :square (* number number)})
       [1 2 3 4 5 6]))

Applications And Capabilities

Most pages need only the core product. An application manifest is added when a page supplies Rasa source libraries, normalized packages, browser providers, policy, or session configuration. It references the core product and owns only its application assets.

import { buildBrowserApplication } from "@rasa/browser/build";

await buildBrowserApplication({
  workspace,
  dist,
  application: { id: "example.music", version: "1.0.0" },
  product: "../rasa/browser-product.json",
  libraries,
  packages,
  providers,
});

Provider modules are fetched as verified bytes before import. Package exports form the default capability policy; applications can provide a tighter policy explicitly. Calls still originate from admitted Rasa capability operations.

Capability projections declare the asynchronous host import and every public evaluation export that can transitively reach it. The application simply awaits Session.eval; it does not install JSPI wrappers or manage component projection details.

Publication

The website assembly contains exactly one core browser product under rasa/. Studio, conformance, proofs, and the inspection workspace all reference it. Assembly rejects section-local runtime copies and source components that should not be deployed.

This boundary keeps the responsibilities narrow:

Rasa core owns language semantics and source artifacts.
@rasa/browser owns product verification, compatibility, capabilities, and sessions.
Applications own examples, browser providers, and presentation.

That is the browser contract: one runtime product, one public lifecycle, and structured evidence at every refusal or execution boundary.