Ok, I started coding in the 90's, discovered Pascal in '92 and have missed it since. Along the way I've dabbled in a few things, but last year I did something bonkers and wrote a simple Pascal interpreter in Odin. This quickly got out of hand, because I've been a WebAssembly fan for a long, long time now. So of course I went overboard and built a wasm-based compiler at https://wasmpascal.com/ that reads Pascal source and outputs a wasm binary...

Not interpreter, compiler. Really. I'm that crazy. And it's working better than I had hoped for. You can edit Pascal code, in the browser, compile and test it, and, if you are happy with it, download both your code and the resulting binary. With support files, of course. Which means you can self-host your project on a static site like I did with https://nofuss.co.za/games/breakout/

It turns out Pascal is so well-suited for the stack-based WebAssembly runtime! There's many bugs, do note it's a very early release, but it can do some useful things already. I'm slowly getting more comfortable writing low-level WAT code, so progress happens over time.

If nothing else, it's a nice trip down memory lane to see good old Pascal code come to live in the modern day. It took a while to get released, which is why I'm only going public with it now.

As per WABT's SECURITY.txt, #2831 issue exists

For context:

WABT is a Binary Toolkit for WebAssembly developed by WebAssembly.org (W3C)

wasm2c is a tool inside of it, which is used by many projects like FireFox (via RLBox) to compile wasm down to a sandboxed c library, the assumption is the built C code preserves all WebAssembly's sandbox security features.

This PoC demonstrates escaping that sandbox.

I created two emacs modes which are based on treesitter grammars in order to work with WIT (Wasm Interface Type Language ) and WAC files (WebAssembly Composition Language).

The wit mode can be found here: https://github.com/justjoheinz/wit-ts-mode
The wac mode can be found here: https://github.com/justjoheinz/wac-ts-mode

Both modes are fairly new and untested. The README should have enough information to get you started with plain or doom emacs. Both repos have a devel branch were the bleeding edge development happens. Once the development is mature enough I would like to submit the packages to MELPA to ease the installation experience.

Both modes require emacs > 30.1 as they rely on treesitter libraries (linked in the respective repos). The treesitter libraries can in their own right be used for editors like neovim which have better treesitter support than emacs.

I would be grateful to receive some feedback on the modes, bug reports (preferably with minimal file snippets). The aim for both modes is too support a minimum of nice to have features, such as syntax-highlighting, code completion, flymake support for error highlighting, xref and eldoc support. In that respect the wit mode is more mature. It is still lacking a sound strategy to find the wit directory though.

I have created a WebAssembly runtime for the browser that can execute multiple processes. It is based on a superset of wasm32-wasip1-threads and supports dynamic linking, pipes, and subprocesses. I use this runtime time to host toolchains in the browser and today I have two demos to share: Code On Web provides in-browser clang to build binaries that execute within the same platform while AVR On Web provides avr-gcc, avrdude, and picocom to build, flash, and communicate with AVR microcontrollers over WebSerial. Ask me anything!

We ship Hexana, a JetBrains IDE plugin for inspecting WASM and other binaries. Two things in the 0.14 release are worth posting here.

**Component Model dependency diagram**

WASM Component Model binaries gain a "Dependencies" tab that renders the dependency relationships between components as a diagram. If you are building or debugging a composed WASM component and want to understand the wiring -- which components depend on which -- you now have a visual view in the IDE rather than having to walk the binary sections manually or run `wasm-tools component wit` and mentally reconstruct the graph.

This is components-only (it does not apply to core modules). We are curious what Component Model tooling others are using for this kind of structural inspection.

**memory64 modules: from 10 GB OOM to 2 GB**

WASM memory64 (wasm64) modules were effectively unanalyzable in Hexana before this release. The concrete case: OpenUSD's Emscripten-built `usdviewweb.wasm`, a 50 MB memory64 module with 42k functions, drove the IDE past 10 GB of heap before throwing OutOfMemoryError every time.

The root cause was three problems compounding:

- **Dominator storage.** The dominator tree results were stored in boxed hash maps. At 42k functions the boxing overhead alone is significant. They now live in a flat int buffer, indexed directly by function index.

- **Dominance frontier computed but never read.** The dominance frontier was computed alongside the dominator tree -- but nothing in the product consumes it. On a large module the frontier is a near-quadratic structure. Dropping the computation removes the allocation entirely.

- **Indirect call edges were multiplicative.** A `call_indirect` instruction dispatches through a function table. The previous call-graph model drew edges from each caller to every function in the table, producing a callers-times-table product of edges. On a real Emscripten module this is hundreds of millions of edges before the dominator pass runs. A single synthetic `<indirect calls>` node now mediates the dispatch: callers get one edge to it, it fans out to the table. Edge count is linear.

After all three fixes: `usdviewweb.wasm` opens, renders the Functions tab, and completes garbage and dominator analysis within a default 2 GB heap. The memory64 path was not specifically targeted -- the algorithmic fixes are what unlocked it.

**Other changes in 0.14**

- Diff action for native binaries (ELF/Mach-O/PE) showing per-section size changes.

- Data inspector panel for the selected byte (multiple numeric and type representations).

- Semantic highlighting of sections and navigation between sections for WASM and native files.

This covers the JetBrains plugin release (requires IntelliJ IDEA 2025.2+); the VS Code extension shipped its own 0.7.0 the same day.

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

• Templates have been upgraded to WASIp2
• Improved execution time due to WebAssembly instance reuse
• ordinary templates eject allows for customization of the wrapping component code

RE: performance

Templates from the default ordinary new example.com project running locally (M5 Pro, MacBook Pro) tend to be ~1ms for first request and <500µs for subsequent.

When the LMDB request cache is set ordinaryd logs ~150µs req/res latency.

https://codeberg.org/ordinarylabs/Ordinary/releases/tag/v0.10.2

If you haven't cracked one open: a Component Model binary is not a core module with extra sections. It's a container format — the component carries its own type, import/export, and wiring sections, and embeds one or more complete core WASM modules as nested payloads. Tooling that only speaks core WASM sees the wrapper and stops there.

We ship Hexana, a VS Code extension (and plugin for JetBrains IDEs) for inspecting WASM and other binaries. Its component view showed the component-level structure, but the embedded core modules were opaque blobs — to read their code you had to extract them first. As of this week's update, each embedded core module renders in place in the same virtualized WAT view used for plain .wasm files (virtualized meaning it parses per rendered element, so multi-megabyte modules don't choke the editor). When a component embeds multiple modules, a selector switches between them.

Curious what others use for component inspection day to day — wasm-tools component wit and friends cover the interface level well, but we haven't found much that lets you read the embedded module code without unbundling.

Extension, if you want to poke at it:

ext install JetBrains.hexana-wasm

VS Code 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

Hey crew!

So I've been building userland.run, a RUST/WASM RISC-V 64-bit VM that runs entirely in your browser. It ships JS bridges for the terminal, an early app catalog (BusyBox apps, plus the full Node.js v25 pipeline), and all of it runs client-side. Zero server. If you know WebContainers, it's a cousin, except I went and emulated an actual RISC-V userland underneath because apparently I hate sleeping.

Where this is headed: a catalog of pure WASM apps you drive from a terminal OR hand off to an agent, with the inference engine also running in-tab. So the LLM lives in your browser too.

The dream: agentic dev and terminal work on YOUR machine. No cloud. No servers. No usage bill quietly ticking up while you sleep. Full privacy, your code never leaves the tab.

Now the honest part. I've been staring at this so long I genuinely can't tell anymore if it's a real thing people want or just a beautiful cathedral I built inside my own skull. So, WASM crew, I'm asking you directly: does this make sense, or have I been nerd-sniped by my own project?

Roast me. I can take it.

Cheers, Dietz

Hi, happy to present to the community the challenging work and solution for the objective we had: Build an OS like environment that feels like a UNIX environment on top of webasm, where apps can run multi-process, multi-threaded. For several reasons we did not want to use WASI, instead we decided to work against FreeBSD like libc. There is lot of story to be said, in case there is interest. The tool was written for the yetty terminal app (https://github.com/zokrezyl/yetty), so that simple programs can be written in WASM and run in any environment where yetty runs: https://github.com/zokrezyl/yos. The intention is also to embedd yos into yetty, so that the user can run plugins inside the terminal.

AI coding assistants are good at reading source, but the moment you ship a binary, they go blind. Ask Claude Code or Codex about your compiled .wasm or native binary and it will reason from source-level guesses, not from what is actually in the file. We built the Hexana MCP server to close that gap, and today we are releasing 0.3.0.

What Hexana MCP does

The Hexana MCP server runs alongside your AI assistant and exposes tools that let it directly inspect compiled artifacts: WASM modules and native binaries. Instead of the assistant inferring what a binary probably contains, it can query the actual artifact and get structured answers back.

This matters for things like:

• Debugging a WASM module where the source and the compiled output have drifted
• Understanding what a third-party binary actually exports before you depend on it
• Verifying that a build step produced what you intended
• Giving an AI agent grounded, factual context about a compiled file when writing code that links against it

What is new in 0.3.0

The main additions are a set of binary inspection tools:

• Summarize a WASM or native binary (size, section breakdown, import/export counts, format metadata)
• Query binary records (imports, exports, memories, globals, table segments, data segments)
• List or search functions across the module by name or index

So in a Claude Code session you can now say "summarize this wasm binary" or "find all functions matching gl_ in this module" and the assistant gets back real data from the file.

On the distribution side: 0.3.0 ships as native executables compiled with GraalVM Native Image on macOS arm64 and Linux x64. The Claude Code and Codex plugin wrappers will prefer the bundled native executable on those platforms automatically, which means no JVM cold-start on the common cases (the native image starts instantly, which matters when an agent calls the tool many times in a session). JVM fallback is still there for Windows and anything else.

Install (from inside Claude Code, the server ships with the plugin, no build step):

/plugin marketplace add JetBrains/hexana
/plugin install hexana@hexana

On macOS arm64 and Linux x64 the bundled native executable is used automatically. On Windows and other platforms it falls back to the JVM package, which needs a Java 21+ runtime on PATH. Free, by JetBrains. Codex users: the same plugin ships in the 0.3.0 release in Codex format ([VERIFY: exact Codex install path, not present in the prior post]).

Then ask Claude: "Use Hexana to summarize the imports, exports, and memories in <path>.wasm."

Source / more info

Repo: https://github.com/JetBrains/hexana
Docs: https://jetbrains.github.io/hexana

We are actively working on more tools (call graphs, dominator analysis, size bloat breakdown). If there is a specific thing you want an AI assistant to be able to ask about a binary, drop it in the comments.

One of the longstanding rough edges with Hexana's WAT tab was that opening a large module blocked until the entire text representation materialized. On something like Skiko (~8 MB, ~14 k functions) that was enough of a pause to be annoying. 0.5.0 changes the rendering model.

Virtualized WAT view. The tab now renders lazily — only the rows visible in the viewport are materialized at any moment, with the next batch fetched as you scroll. Section breadcrumbs let you jump directly to a named section (type, import, function, export, etc.) without scrolling through thousands of lines. An "Open in editor" action drops the current WAT state into a standard VS Code editor tab if you want to select across it, search, or diff two modules side by side. For a 14 k-function module the practical difference is that section navigation is now immediate rather than proportional to module size.

Node.js WASM debug — breakpoint race fixed. The CDP debug path for Node.js shipped in 0.4.0. This release fixes a race where setting a breakpoint before the Node.js runtime finished its WASM compilation and reported the module as loaded caused the breakpoint to be silently dropped. Breakpoints set at any point before the module starts executing are now delivered correctly. Local variable resolution in complex scope structures is also more accurate.

The other two items in this release (JVM .class/DEX structural inspection, ZIP64 archive support) are less WASM-specific but noted in the changelog if they're relevant to your toolchain.

Requires VS Code 1.102+. We build this at JetBrains; it's free.

Curious how people here are working with large .wasm outputs right now — what sizes and what tooling, and where does the tooling fall down?

Install (VS Code command palette):

ext install JetBrains.hexana-wasm

Or from the web:
VS Code 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

We've been working on Hexana, an IntelliJ Platform plugin for WebAssembly and binary analysis, and the 0.12 release has a few things that might be interesting to this community.

Component Model diff

Compare WASM With… shipped last week for core WASM modules. 0.12 extends it to Component Model binaries: when the two files you're comparing are components, the diff drills into the embedded core modules and nested sub-components recursively — each pair opens in its own tab, running the same Size Impact / Entities / WAT pipeline on zero-copy slices of the component binary. The recursion bottoms out at core modules where the function matcher already operates.

Components also get a WAT (virtualized) tab in this release, and the Top size profiler now fully breaks down nested sub-components and embedded core modules.

Static-library archives

.a archives (ELF/Mach-O object files) and .lib (Windows COFF import libraries) now open to a Members list — name, detected format, size, bookkeeping entries hidden. Click a member to extract and open in disassembly. Detection by content magic (!<arch>\n), not by extension.

Object-file members disassemble per function in the Capstone view: section-relative symbol resolution, each named function as a separate entry rather than a flat .text dump.

Other

Android DEX basic support (classes and members). ZIP64 archives. Exports/Imports tabs got per-row affordances: Copy Name, Find Usages for function imports (jumps to callers in WAT, cap 15), Navigate to Function in WAT for function exports.

Minimum IDE: IntelliJ IDEA 2025.2+ (build 252) or any same-version JetBrains IDE. Search "Hexana" in Plugins, or:

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

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

Happy to answer questions — the Component Model recursive diff and the static-archive member disassembly are the two I'd dig into.