Give an idea a place to run.

1. Try a calculation

Open the motion example, or choose an example in Syntax. Edit the source and press Run. The compiler runs in a Web Worker on your device; output stays empty until execution.

For a local page, download the embedding starter and serve it over HTTP. The starter lets an HTML input provide a number to an actual VKF program.

2. Use the native CLI

These are the CLI forms implemented in the source driver. They require a separately built native compiler on your PATH; the browser download does not install vkf. Native CLI execution is not requalified by this website check.

vkf -v
vkf -e ':: 2 + 2'
vkf model.vkf
vkf -b model.vkf -o model
./model

CLI source reference: bootstrap 31306896aff2757724aec6428cb315c6d1a7eeb1, vkf_driver_artifact_smoke.cpp. The installed target determines the executable format; this table does not promise cross-compilation.

3. Check the relationship you depend on

Keep a small input and an expected result together. This runnable assertion program checks the smooth path’s endpoints and midpoint. For native test discovery, use your compiler’s test convention and run vkf -t on that file or directory.

p(t):3*t^2-2*t^3
(p(0)=0)?! "start"
(p(1)=1)?! "end"
(p(0.5)=0.5)?! "midpoint"
::"passed"

passed

Change one expected value to see the compiler report a failed assertion. Browser Run executes this program; it does not invoke the native test-discovery CLI.

4. What the browser compiles

The shipped compiler is itself WebAssembly. It parses VKF source and produces a program WASM module plus a manifest and typed IR. The worker compiles that module, instantiates it, invokes the program entry and formats output. Visual results use retained-scene packets.

The starter uses this same path. It is not a separate JavaScript implementation of the calculation. createInlineRunner().run(source) wraps the worker lifecycle; loadCanonicalBrowserCompiler().compileSource(source) is the lower-level API for program bytes and manifests. Use the helpers and runtime from the same package.

The source driver’s internal WASM artifact tooling is distinct from the small native CLI above. This guide does not invent a public vkf --wasm command.

5. Connect HTML to a real VKF program

Open the working embedding example. It reads a number from an HTML input, passes a VKF program to the worker and displays the returned stdout. Its source is included in the complete starter bundle.

import {createInlineRunner} from "./inline-runner.mjs";
const release = await fetch("./current-compiler-release.json").then(r => r.json());
const runner = createInlineRunner({
  moduleURL: release.package.module,
  wasmUrl: release.package.wasm,
  dataURL: release.package.data
});
const result = await runner.run("square(x):x^2\n::square(5)");
document.querySelector("output").textContent = result.output.stdout;

The complete page handles loading, numeric input validation, errors and reruns. Keep its same-origin worker paths and compiler pins. For plots, use the matching retained-scene renderer; the homepage’s actual program demonstrates that path.

6. Serve the files together

Use HTTPS in deployment or localhost while developing. Serve .wasm as application/wasm and module files as JavaScript. Keep the folder structure and third-party notices.

The runner needs an isolated browser context for shared memory. Serve Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, or keep the supplied isolation service worker. On a host without those headers it can reload once to establish isolation. Do not remove vkf-coep-sw.js.

The website runner exposes the browser subset. Native filesystem and OS-command capabilities are unavailable to user programs here. Programs that need unsupported capabilities should report an error.