Add JZ WebAssembly kernel example

[dy]

Add JZ WebAssembly kernel example

Adds examples/jz-kernel. jz compiles a JavaScript-subset numeric kernel to standard WebAssembly; EdgeJS loads it through WebAssembly.Module / WebAssembly.Instance. JZ is used as a kernel compiler, not as a JavaScript engine for EdgeJS.

Reproduce

From examples/jz-kernel:

npm ci
edge bench.mjs

Local EdgeJS native result (4x4 Float64Array matrix kernel, 200k iterations, 9 runs after 5 warmups):

imports: 0
wasmBytes: 919
checksum: 50495773 (raw JS == JZ WASM)
raw JS median: ~12.6 ms
JZ WASM median: ~8.3 ms

Limits

• Not an EdgeJS engine integration.
• No safe-mode claim; local safe-mode is blocked before user code by missing Wasmer N-API features (napi_v10 / napi_extension_wasmer_v0).
• No CI; the example would need a networked install of jz@^0.1.1.

[syrusakbary]

Awesome, great first step.
Ideally I'd like to see JZ as another engine supported by Edge.js. But perhaps that might be better done in another PR. Thoughts @dy ?

[dy]

@syrusakbary so how do you see JZ integration the best way? I lean to option 2, I could fix compat layer.
Some node modules can be added via WASI: fs, time, crypto. Some host env import can enable simplified fetch.
Also I am finishing metacircularity (jz.wasm) - that needs to be done before integration.

Integrating jz as an alternative JS engine in edgejs is fundamentally different from integrating V8, JavaScriptCore, or QuickJS.

The Core Mismatch

Edge.js is built around N-API (Node-API). It boots up by evaluating complex dynamic JavaScript (lib/internal/bootstrap/*.js) using napi_run_script, creating dynamic objects, closures, and managing Garbage Collection.

jz is a static compiler for a numeric/array subset of JS with no GC, no object prototypes. It outputs raw WebAssembly.
Therefore, jz cannot act as a full napi/jz provider to boot Node.js core modules (fs, http, etc.). It would fail to process EdgeJS's own internal Javascript.

How Integration Is Possible

Despite the mismatch, jz can be integrated at a different architectural level. Here are the realistic paths:

1. The "Sub-Engine" (AOT Kernel Compiler)

EdgeJS retains V8/QuickJS as its primary runtime (to handle N-API and Node compatibility) but embeds jz natively to accelerate pure math/DSP/array workloads.

• EdgeJS intercepts imports (e.g. files with "use jz" or .jz extensions).
• EdgeJS automatically runs the jz compiler on the script.
• It instantiates the resulting WASM via Wasmer instantly and returns standard JS wrappers.
• Pros: Seamless DX. Users get native Node.js capabilities + instant WASM speeds for hot routines.

2. The "Bare-Metal WASI" Engine Mode (edge --engine=jz)

EdgeJS bypasses standard Node initialization entirely if jz is selected.

• Command: edge run --engine=jz compute.js
• Under the hood, EdgeJS runs the jz compiler (either using a tiny embedded QuickJS instance or pre-compiled JZ-in-WASM).
• It takes the generated .wasm, hooks it up to Wasmer with WASI context, and runs it.
• Pros: Pure, blazing-fast sandbox. No Node.js overhead.
• Cons: The script cannot use require('node:fs') or general JS APIs. It is limited to exactly what jz supports + WASI.

3. A Minimal napi/jz Facade (Not Recommended)

You could implement a napi/jz layer where napi_run_script compiles to WASM and primitive types (napi_create_double, etc.) map to WASM memory.

• Cons: You'd have to stub out 90% of N-API. EdgeJS wouldn't be able to boot its normal environment.

Summary

As a drop-in replacement for V8 to run standard Node apps that's practically impossible without rewriting JZ into a fully dynamic JIT/interpreter.

However, if the goal is to make EdgeJS the first runtime to natively support "JS-subset to WASM execution" out of the box (either dynamically accelerating hot functions via Option 1, or treating Edge.js as a WASI runner for JS via Option 2), that provides massive value and perfectly fits Edge.js's vision of WASM computing.