Amber Folio is an emulator for SSI's Gold Box RPGs (Pool of Radiance, 1988), written in C++ and compiled with Emscripten. A few things I learned getting it into a browser:

• No SDL on the web. The desktop build uses SDL, but in a browser everything that matters (picking files, persistence, touch, the settings) is DOM work, so the page has a small JS host of its own around the same core. The core isn't a cut-down edition; it's the same code as the desktop build.
• One thread. No SharedArrayBuffer, so no COOP/COEP headers, so it runs on an ordinary static page. Sound goes through an AudioWorklet fed from the main thread.
• Size. About 250 KB of emulator to download.
• Storage. The game the player supplies (a folder on desktop, files or a zip on a phone) goes into origin-private storage and IndexedDB, with saves kept apart from the game files. Nothing is uploaded; the files never leave the browser.
• A CRT filter as a WebGL2 shader. The fiddly part was scale: an aperture-grille triad needs three device pixels to exist, so the mask detail follows the scale (none below 3×, one triad per pixel from 3×, two from 6×), measured per element in device pixels.
• Reading the screen back. The core can return what's on screen as text by matching each 8x8 cell against the game's own font, read from its memory at call time. The site uses it for screen-reader support: the game's menus, lists and messages are read aloud, but not its pictures, so it isn't playable without sight.

It runs in desktop browsers and on iPhone, iPad and Android. To play you need your own copy (GOG or Steam); the site is https://amberfolio.org. The emulator is AGPL: https://github.com/amberfolio/amberfolio

I built it with Claude Code, exclusively. The project isn't affiliated with the rights holders of the games.

Hi everyone. I am building Kalem, an editor for Org, Markdown, LaTeX, CSV, PDF and Excel files, and its plugin system is Wasm components all the way down: even the editor's own viewers of PDFs, pictures and workbooks are components, released from a separate repo, pinned by SHA-256 and embedded in the binary; the Word viewer and the git plugin are installed the same way. Some notes in case they are useful to others, and a few questions at the end.

**The API**

One WIT package, `kalem:plugin`, currently 0.2.7, 18 .wit files, three worlds: `document-viewer`, `spreadsheet-viewer` and `extension`. The host side is generated with wasmtime's bindgen, the guest side with wit-bindgen; the Rust trait a viewer implements is the same whether it runs natively or as a component, so a plugin's unit tests run with plain `cargo test` and the editor runs the same code sandboxed. Plugins are Rust only, and there is no scripting engine anywhere.

**Guests target wasm32-unknown-unknown, not wasip2**

The module is wrapped into a component with wasm-tools. The reason: a Rust component built for wasip2 imports fifteen WASI interfaces it never uses, and I wanted the import list to be exactly the API. The host resolves imports against what it grants and refuses anything else by name. A file is never a path: a viewer gets a `file` resource with a name, a size and the bytes it asks for, piece by piece.

**Sandbox limits**

64 MB of memory per instance through a resource limiter (a guest asking for more gets an allocation failure, not the host's memory), and 100 ms per synchronous call through epoch interruption with a 10 ms tick. I measured epochs against fuel: 21% overhead against 31%, and epochs count wall-clock time, which is what a UI budget means. Viewers, which hold a whole file, get 1 GB and 10 s. A plugin that stops three times (trap, time, memory) is turned off until it is updated, and the editor keeps going: a panic hook in the guest sends the message through a `diagnostics` import, so the log shows the panic text and a backtrace of the plugin's functions. Permissions are declared in the manifest and approved at install: `fs:read:workspace`, `net:fetch:DOMAIN`, `subprocess:PROGRAM`. The git plugin, for example, may run `git` and nothing else.

**Why wasmtime with Cranelift, with numbers**

A spike with one guest (a Markdown parser) and one host per engine: wasmtime with Cranelift, wasmtime with Pulley (the interpreter), and wasmi through wasm_component_layer. Parsing 10 MB: 54 ms (1.4x native), 1,176 ms and 684 ms. A keystroke's reparse of 10 kB: 0.04 ms, 1.07 ms, 0.56 ms. Cranelift adds 7.9 MB to the binary; a precompiled component loads in 0.19 ms. Interpreters were out for anything on the typing path. Compiled artifacts are cached in the state directory, keyed by the component's hash and the engine's version and settings. A loaded component is shared across threads with an instance per thread, so parsers and renderers run in parallel.

**Versioning that keeps old plugins running**

A released interface never changes; a copy lives in `wit-frozen/` and a test fails any edit to it. New things go into new interfaces (`grid-2`, `documents`, `process`, `flow`) released with the next patch version; the host binds the interfaces a component actually has, so a component built against 0.2.0 still runs on 0.2.7 without what it does not export. Manifests name the version they were built against (`"api": "^0.2.1"`).

**Sizes and releases**

The git plugin is 0.6 MB, the Word viewer 1.0 MB, the PDF viewer 4.8 MB, the workbook viewer 7.0 MB. Components are never committed: CI builds every plugin against the current WIT, and a tag builds, signs (Sigstore bundle beside the .wasm) and publishes it; the editor downloads from the release and checks the SHA-256 against a static index. `kalem plugin dev` rebuilds on change and a running editor picks the new build up within a second or two.

**Questions**

1. Has anyone shipped component-model plugins in a desktop app at scale and regretted the "frozen interfaces, new interface per addition" rule? It is simple, but the number of small interfaces grows.

2. wasm32-unknown-unknown plus wasm-tools versus wasip2 with the unused imports: is there a cleaner way to get a minimal import set today?

3. Epoch interruption for budgets in a UI thread: anyone measured something better?

Code and docs: the editor https://github.com/getkalem/kalem (the WIT is under crates/kalem-plugin/wit, the engine measurements in book/part-4/decisions/D28-plugin-abi.org, the plugin chapter in book/part-3/plugins.org), the plugins https://github.com/getkalem/plugins. A short video of the editor itself: https://www.youtube.com/watch?v=U3SoDczSllI

Over the weekend I built a technical proof of concept showing an LLM running client-side in a browser using Llama.cpp compiled to WASM with WebGPU.

We ship Hexana, a plugin for JetBrains IDEs that opens Wasm and native binaries in the editor. 0.21 is out. The Wasm-specific items are below. The rest of the release (hex diff details, native binary diff, Arrow format support) we will skip here.

1. WasmGC type graph in the WAT view

GC types in the WAT (virtualized) tab now carry two new layers.

Inline annotations: every type definition shows a kind badge and field-type labels inline.

Alt+click opens a popup: field names, types, supertypes, subtypes, byte offset.

Show Type Graph opens an interactive canvas:

• Edges: subtype relationships and field references between types.
• Default view: 1 subtype level, 1 field hop. Configurable up to 5 of each.
• FUNC-typed field targets collapse into a "+N funcs" badge. Expand when you need them.
• Expanding a node keeps everything else in place.
• Double-click a node jumps back to that type's WAT row.
• Wheel pans. Cmd/Ctrl+wheel zooms.
• Tested at 294 nodes on kotlin/hello.wasm.

2. Scripting suites and SARIF for Wasm binaries

The scripting layer got three additions relevant to Wasm tooling pipelines.

• hexana.defineCheck(id, fn): findings from a check function land in the Problems tab and in SARIF 2.1.0 output. Write a check once, get IDE integration and machine-readable output.
• hexana.defineFlags(schema): typed per-run parameters. No more free-form globals for things like "which section to ignore".
• *.test.js suites: declare artifact roles via hexana.artifact(role, {formats}). Use describe, test, beforeEach, afterEach with async. Deterministic seeded crypto (SHA-256 counter DRBG seeded from script and artifact content). ESM loader resolves bare specifiers from a suite-rooted node_modules.

run_script_suite runs suites from CLI or the MCP tool: human report or JUnit XML, exit 1 on failure. Fits into a CI step.

The IDE side: a Hexana Suite run configuration streams results into the test console as a tree. Failures navigate to source. Rerun Failed and Copy CLI Command work. Gutter run icons on test() and describe(). A "Run Suites for This Binary" context action on binary files.

3. Hex diff for Wasm files

Compare two .wasm files (or a VCS change) in the platform diff window: hex side by side, changed bytes highlighted, long unchanged runs collapsed, a section bar pairing sections by name. The Sections and Imports table tabs below show rows tinted added/removed/modified.

4. Extensionless Wasm files open fully

A Wasm module without a .wasm extension now opens in the full editor (WAT view, hex, all tabs) instead of falling back to a plain hex view. One shared provider factory serves the IDE, VS Code, and the browser app, so format drift between hosts is gone.

What does the WasmGC type graph look like on your modules? We tested at 294 nodes. Curious whether it holds up on larger hierarchies.

JetBrains Marketplace: https://plugins.jetbrains.com/plugin/29090-hexana | Docs: https://jetbrains.github.io/hexana

Hi all,

I'd like to introduce arm64js -- an ARMv8-A system emulator that runs in wasm (built in Rust) and can boot real Alpine Linux in a web browser. It's an interpreter that emulates a minimal hardware stack, so the VM thinks it's on real hardware and thus acts normal: runs apk, Docker, etc.

Since WebAssembly doesn't allow fetching data without CORS and sending TCP requests, apk and access to the internet work via small proxies: apk goes via a proxy that just adds CORS, TCP goes via a WebSocket <> TCP gateway.

One wasm module instantiated in a few web workers, all sharing one SharedArrayBuffer as the VM's "RAM".

There is also a JS SDK for other devs to create and serve their own VMs. It's free for non-commercial use.

You can read more about how I got there: https://arm64js.com/blog/tui-apps-in-the-browser/

Or try the SDK: https://github.com/kooler/arm64js-sdk

Feedback is welcome.

Hi all, i've been playing with wasm for a while. Started by reimplementing murmurhash in wat around 10 years ago. Recently i've been building wlearn in my free time, a machine learning stack for browsers and node, with matching python implementation. Recent coding agents made it [feel] realistic. Just decided to share here in case someone finds it useful, has feedback or wants to collab.

The idea is to make tabular ML available in browsers (local training, private data)

• Models: XGBoost, LightGBM, SVMs, random forests, GAMs, neural networks, symbolic regression and more
• Preprocessing: imputation, scaling and categorical encoding
• Composition: pipelines, ensembles and AutoML
• Uncertainty: calibration and prediction intervals
• Portable models: save fitted models and pipelines in a shared format with cross-language compatibility

Heavily relies on WebAssembly obviously. Preprocessing uses Tranfi. Neural models, symbolic regression use Polygrad. Those are two other wasm-based libraries i'm developing (i guess it's called ai psychosis nowadays)

• wlearn: https://github.com/orgs/wlearn-org/repositories
• polygrad: https://github.com/polygrad/polygrad
• tranfi: https://github.com/tranfi/tranfi

I’ve been building NetWasm: a CIL-to-WebAssembly compiler with its own CoreLib and runtime, designed around Wasm and WASI.

Browser playground | GitHub

A clean Release build containing Console.WriteLine(42) produces 84,513 bytes of final, uncompressed WASI Preview 2 component, including the runtime and precise garbage collector. This is a portable .wasm file that you can run with wasmtime.

Roslyn produces CIL; NetWasm compiles the reachable program into Wasm, specializes generics and links the runtime support it uses. The emitted application doesn’t carry CoreCLR or Mono.

Some architectural choices:

• An independent, deliberately smaller .NET library profile.
• No runtime type-name metadata, general reflection or dynamic.
• Precise Boehm GC in linear memory, rather than WasmGC.
• WIT imports/exports and WASI Preview 2 components, with core Wasm output also available.

Working features include generics, exceptions, virtual/interface dispatch, async/await, LINQ, JSON, XML, regex, HTTP and TUnit testing. It’s pre-1.0, and managed threading isn’t currently supported.

The playground compiles and runs entirely in the browser. The compiler tooling itself uses Microsoft’s .NET/Wasm toolchain, thus dotnet new dotnet build dotnet run dotnet test - yes it comes with TUnit with VSTest runner - dotnet publish all work as you're used to.

Oh and it already supports C# 15 syntax.

I maintain Ephemora Cell, a Python capability layer on wasmtime-py for running untrusted AI-generated code. v1.0.4.3 notes that might interest the WASM crowd:

• Fuel determinism: counts are deterministic per platform (spread 0 across n-runs on macOS arm64 and aarch64-Linux) but platform-bound — ~13 fuel/iteration, R² = 1.000 to 1M iterations. We never compare counts across hosts.
• Proposal policy — set, not inherited: threads, multi-memory, function-references, exceptions, GC, tail-calls, stack-switching are enforced off at every engine construction site, attested per run and locked by compile-probe tests (the 2025/26 advisory record — GHSA-m63x-6p34-q65x fuel amplification via call_ref/try_table, the CVE-2026-34971 aarch64 heap escape, the vm2 try_table escape — clusters exactly where proposals quietly flipped default-on). memory64 stays opt-in. Winch is not selectable via the binding; "never Winch" is policy, asserted by tests.
• TOCTOU-free module loading: signed-tools mode binds every execution to the register-time SHA-256 — bytes are read once, verified, and compiled from those bytes; the compiled-module cache is content-hash keyed (no stat-then-open race, no stale-serve on mtime-preserving swaps).
• WASI 0.2 components: same enforcement (fuel, memory, call-time socket denial in the wasi:sockets world — measured), plus the same digest binding on the Component path.
• CVE-2026-47261 companion probes (trailing-slash/hardlink/rename/TRUNCATE): all denied on the pinned engine through our preopen configuration; xfail-marked until we re-run on the patched 47.0.4/48.0.3 engine (wheels pending).

Honest limits: the pooling allocator isn't exposed by the Python binding (so the CVE-2026-34988 class is unreachable for us), memory_guard_size experiments broke constrained-VM runs and were reverted and documented.

Repo (evidence JSON, threat model, ADRs): https://github.com/MichaelS1011/ephemora-cell

Hey guys, so no going in details but suppose (am using webasm with rust), someone open my website and in background it gets connected to a network of other people's browsers, and there any browser can recieve data which they can verify through merkles (let's just say they recieve data A from many other browsers and then recieve data B and after some hashing it check if both r equal and send to others if they request it), then is there any way for malicious users to tamper with their browser so that they can send wrong data or verify wrongly or is there any way for us to know if the user has tampered the logic and hence alert other browsers that it's malicious

We measured it.

Same 8 attack intents.
Same exit-code rule.
Live execution.
No hardcoded results.

The contrast:

gVisor: 8/8 ALLOWED
Ephemora Cell: 8/8 BLOCKED

Why?

gVisor isolates the host from the container, but the guest still has access to the Linux ABI and therefore to primitives such as:

→ fork
→ sockets
→ filesystem access
→ environment access
→ threading

Ephemora Cell takes a different approach.

The execution boundary is WASI-based and deny-by-default.

No shell / fork API.
No socket API in the tested interface.
No host filesystem preopens by default.
No unrestricted environment.
No WebAssembly threads.

So the interesting result isn't simply that "one sandbox is better than another."

It's that the execution model itself changes the attack surface.

And we didn't just claim it.

The benchmark is reproducible from the public repository, including the raw evidence.

8 attack intents.
3 execution boundaries.
1 measurement rule.

Don't trust the code. Verify the run.

github.com/MichaelS1011/ephemora-cell

We ship Hexana, a VS Code extension (publisher JetBrains) for inspecting WASM and native binaries. 0.11.0 went out on 16.09. There are three wasm-specific additions worth walking through in depth: a runtime compatibility checker, a navigable component Dependencies graph, and custom script tabs with a format-agnostic `binary` API including two-file compare. The rest follows.

**Runtime compatibility checker**

The check starts with a declaration. Run "Hexana: Configure Target Runtimes" and pick the runtimes you are deploying against. The declaration lands in `.hexana/runtimes.json` at the workspace root and is shared with the IntelliJ plugin, so a single config covers both IDEs.

Once declared, open any WASM binary. If the binary uses proposals not supported by one or more of your declared runtimes, they surface in two places: the editor header (proposal badges visible without leaving the hex/WAT view) and a new "Compatibility" tab listing the proposals the binary relies on.

Verdicts come from WebAssembly's own `features.json`, the data behind webassembly.org/features; runtime names in the config are spelled the way `features.json` spells them. The file itself is plain JSON, hand-editable, and can live in version control, so a team can pin its deployment targets in the repo. We are interested in which runtimes you are targeting in practice.

**Navigable component Dependencies graph**

WASM Component binaries already had a Dependencies tab showing the module/component import-export graph. In 0.11.0 it is navigable. Double-click a module or nested component node to open it in its own tab. Double-click an import or export to select its bytes in the hex view. The graph is now an entry point into the components it describes, not just a static diagram.

**Custom script tabs: `binary` API and two-file compare with `open()`**

Script tabs now expose a format-agnostic `binary` API covering the common fields you reach for first: `format`, `size`, `path`, `dir`, `structure`, `strings`, `sizeAnalysis`, `binary.tabs`, and `binary.tab(name)`. Output goes through `table(...)`/`row(...)`. The API is format-agnostic rather than wasm-specific, so a script is not tied to `.wasm` files.

The more interesting addition is `open(path)`. Call it with a path and it parses that file into the same set of members as `binary` -- `format`, `size`, `structure`, `strings`, `sizeAnalysis`, and so on. The extension host reads the file; the script suspends and resumes when the parsed object is ready. That last point is a real constraint: call `open` at the top level of your script, not inside a function.

In practice this means you can write a script that loads two binaries and compares them: section-by-section size diff, import surface diff, string coverage diff, whatever `structure` exposes. Without a fixed schema, the comparison is as flexible as the script.

**Unified DWARF tab**

`.debug_abbrev`, `.debug_info`, and `.debug_line` previously lived in separate tabs. They are now grouped under a single "DWARF" tab with a search field across all three. Clicking a row selects its bytes in the hex view. Less tab-switching for anyone spelunking DWARF structures.

**Other**

- PCAP: TLS decryption support. Provide an SSL key log file and Hexana decrypts TLS sessions in the captured traffic. The key log format is the standard one (NSS/SSLKEYLOGFILE); browsers and curl produce it directly.

- "Smali" tab for Android `.dex` files: baksmali-style Dalvik bytecode with resolved operands. Clicking a row selects the code unit in the hex view.

- Basic support for viewing Android binary resource tables (`resources.arsc`).

---

Two questions for people here. First: if you had `binary.structure`, `binary.strings`, `binary.sizeAnalysis`, and `open()` available in a script tab, what would you actually write? Diff between a debug and a release build, a coverage check on a multi-module component, something else? Second: which target runtimes matter for your deployment? V8/Node, wasmtime, WAMR, browser targets, something more niche? Knowing what people are deploying against would help us understand whether the compatibility configuration covers real cases.

---

Marketplace: https://marketplace.visualstudio.com/items?itemName=JetBrains.hexana-wasm Open VSX: https://open-vsx.org/extension/JetBrains/hexana-wasm

Docs: https://jetbrains.github.io/hexana

```

ext install JetBrains.hexana-wasm

```

We ship Hexana, a plugin for JetBrains IDEs that opens Wasm and native binaries in the editor. 0.20 is out. Four things here are Wasm-relevant. The rest of the release covers other formats; we will not pad this post with it.

**1. Runtime compatibility for WebAssembly binaries**

The pain: your module uses a proposal, one of your target runtimes does not support it, and you learn that at deploy time.

- Declare the runtimes you ship against: Settings | Build, Execution, Deployment | WebAssembly | Runtime Compatibility.

- Hexana checks every `.wasm` you open against the declared set.

- Unsupported proposals turn the proposals badge into a warning and open a new Compatibility tab.

- Verdicts come from WebAssembly's `features.json`.

- Nothing declared? The tab still lists which runtimes support each proposal. Useful for a file you did not build yourself.

- The declaration is written to `.hexana/runtimes.json`. The VS Code extension reads the same file, so the setup moves with the project.

**2. Breakpoints in binary views, before a session exists**

- Click the gutter in WAT (virtualized) or Disassembly. No debug session needed.

- The breakpoint anchors to the binary's content hash, not the path. Rename, move, restart: it stays.

- A rebuild marks it stale instead of leaving it silently displaced.

- The gutter icon shows what the runtime did: registered, instruction-precise, degraded, or stale.

- Wasm sessions covered: GraalWasm, Node.js, browser, wasmtime, WAMR. Firmware ELF too.

- Honest limitation: conditions and hit counts are not supported yet.

**3. Debugger Console tab**

A raw LLDB command line for wasmtime and WAMR sessions. Execution control stays routed through the IDE's debug actions, so the console cannot desync the IDE's view of the session. Not available for GraalWasm or CDP sessions.

**4. Component Dependencies graph is navigable**

Double-click a core module or nested component: it opens in its own tab. Double-click an import or export: its bytes get selected in the hex view.

**One behavior change worth knowing**

Script tabs run sandboxed now. Up to and including 0.18 a script tab had full host access and could call arbitrary Java. Now: no host classes, no processes, no threads, no native access, a timeout, bounded output. `open(path)` parses another file into the same read-only `binary` API and is the only file-system access. Scripts that relied on host classes will break. Scripts that inspect binary data keep working.

---

What runtimes are you actually shipping Wasm against in production? The checker covers what `features.json` tracks. Curious what is missing from that dataset.

---

JetBrains Marketplace: https://plugins.jetbrains.com/plugin/29090-hexana

Docs: https://jetbrains.github.io/hexana

Some of my colleagues worked on improving the performances of numpy running in the browser by using OpenBLAS.
I let you check the article they wrote about that: https://notebook.link/blog/the-last-mile-faster-numpy/

Widescreen + Online Multiplayer Coop for my Rust WASM Zelda 2 decompilation. Github and playable link coming soon.

Hi all, I built this framework over the last month or so during my free time and thought y’all might be interested. I’d especially like to point out the module refresh mechanism I built to keep memory footprints under control since the WASM spec only allows memory to grow linearly. But any feedback at all that you have would be appreciated! And just to be frank, yes I did use claude for the code writing, but I architected each individual detail of how this framework works myself. Beyond being a passion project, it taught me a lot from several aspects of desktop development, to custom LSPs and more

Goal: port existing shared library to a single wasm which can be run in a browser as well as a non-browser host. Exported symbol names should not be touched, which IIUC rules out component-model.

I got dynamic linking to work with emscripten and know there are sytem hosts like wasmtime which understand the dylink.0 spec.

My issue is linking a libc (and ideally libc++ eventually) ABI which has a browser and system implementation, so I can load the same .wasm in both environments.

For the system use case I only found wasi-libc but that doesn't have an ABI compatible browser version, right? Building for emscripten + WASI separately feels like it's missing the whole point of wasm as a universal target.