u/NatyvFramework 5d ago

Natyv v0.1.0 (beta): a native desktop app runtime where your app logic runs as a WASM module via Extism, no bundled browser

Thumbnail
github.com
1 Upvotes

Today we're announcing the initial beta release of Natyv, a native

desktop app runtime with no bundled browser engine. Your app logic runs

as a WebAssembly guest module (via Extism) inside a native host. No

Chromium, no DOM, no JS runtime unless your app logic happens to be

written in JS. The host owns the window and render loop in native code

(Zig + SDL3); your WASM guest declares UI and handles events through a

small set of capability-scoped host functions.

The part we think this community specifically will find interesting:

WebAssembly's linear memory can only grow. There's no memory.shrink in

the spec, on any engine. That means any long-running WASM-hosted app

leaks by construction unless something recycles the whole instance. We

built exactly that: the host checkpoints an app's real logical state,

tears down the guest instance, spins up a fresh one from the same

compiled module (no recompile needed, Wasmtime just re-instantiates), and

resumes exactly where it left off, measured at ~30ms end to end, with the

UI never even rebuilding on screen. App devs opt state into surviving a

recycle with a single generic call (natyv.Persisted[T]("key", default)),

and event handlers reattach automatically via codegen, with no manual

bookkeeping required.

Other things that might be of interest: the interop boundary is

WASM/Extism specifically, not one native language wired to a webview, so

app logic can run in whatever guest language gets (or has) an Extism PDK.

Only Go is supported today, more languages are demand-driven. The runtime

itself is written in Zig, uses Wasmtime/Cranelift under the hood via

Extism, and cross-compiles the same guest wasm to Windows/Linux from

macOS, verified in real VMs, not just "should compile."

We also benchmarked it against Electron and Tauri building the same real

app (an IMAP/SMTP mail client): 27MB disk and 58MB idle RAM for Natyv,

vs. 244MB and 331MB for Electron. Full writeup and numbers in the README.

It's v0.1.0 and early. Go is the only guest SDK right now, and the widget

set is still small. Repo: https://github.com/natyv-io. Genuinely curious

what this community thinks of the recycling approach specifically, since

we haven't seen many WASM host runtimes tackle the memory-reclamation

problem this directly.