
r/WebAssembly

Hexana now has documentation — jetbrains.github.io/hexana
Hexana is a WebAssembly and binary analysis toolkit by JetBrains. Until today, the only places you could go to figure out what it does were:
- the JetBrains Marketplace listing (per-version changelog), and
- the VS Code Marketplace / Open VSX listings (release notes only).
That's not enough surface for a tool that does multi-tab .wasm inspection, WAT/WIT language support, structural analysis, an MCP server for AI assistants, run/debug, DWARF source mapping, and Java embedder support across Wasmtime / WAMR / GraalVM. So: https://jetbrains.github.io/hexana
What's there
- Two flavours, side by side. Hexana ships as a JetBrains IDE plugin (IntelliJ IDEA, RustRover, WebStorm, GoLand, CLion, PyCharm, etc.) and as a VS Code extension. The docs cover both, and there's a "Choosing between the two" page for when it's not obvious which one fits. In practice today: VS Code is the lighter read-only view; the JetBrains plugin is where the debugger, multi-runtime run configs, and MCP live.
- Wasm coverage documented. Core, Component Model, GC, SIMD, Threads, Tail Call, Reference Types — and what Hexana actually does with each.
- Runtimes. Wasmtime, WAMR, GraalVM — what's selectable where, and which combinations the debugger supports today (LLVM ≥ 22.1, Wasmtime or WAMR, lldb-debuggable target).
- Per-flavour pages. Getting Started, Features, Settings, Troubleshooting, Changelog — for each.
What this is not
- Not a one-size-fits-all docs site pretending the two flavours are at parity. JetBrains plugin is 0.9 (May 7). VS Code extension is 0.0.2 preview (May 7). The docs match reality on the ground — the JetBrains side is broader because the plugin is broader.
- Not an internal-API reference. It's user-facing.
Links
- Docs: https://jetbrains.github.io/hexana
- JetBrains plugin: https://plugins.jetbrains.com/plugin/29090-hexana
- VS Code (install):
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
If anything in the docs is wrong, unclear, or missing — that's exactly the feedback we want right now.
Case study: shipping ffmpeg, whisper.cpp, Tesseract, Pandoc, and Magnum in one client-side file converter
WebConverter.app is a production attempt at the "no server, just WASM" model for file conversion across images, audio, video, PDF, OCR, speech to text, and documents.
The individual modules are mature. Most of the work was integration and slimming: reducing wasm size by compiling feature subsets, lazy loading large modules per route to be graceful towards 2G/3G users, coordinating Web Workers for batch jobs, and keeping cold start latency tolerable.
Curious whether others have hit different walls with this approach, especially around memory limits on mobile Safari for the bigger toolchains.
I spent months fighting VS Code webviews, so I built an open source universal extension protocol using React/WebAssembly
Hey Folks,
This project started because I simply wanted to build a new IDE to fix my own workflow bottlenecks. But I immediately hit a brick wall trying to build the tooling for it. I spent months, days, and nights trying to hack and fix VS Code extension webviews just to get a decent UI to render.
I realized I was fighting a 33 year old architectural problem: extension vendor lock in. If you want your dev tool to reach people today, you have to write Electron/TypeScript for VS Code/Cursor, and Kotlin/JVM for JetBrains.
So I stopped building the IDE, and I built the fix instead.
Meet OXP (Open eXtensions Protocol).
OXP is an open source universal standard that lets you write your extension once in React/WASM and run it natively across every major editor.
How I fixed the Webview problem:
This isn't a slow iframe hack. OXP uses a secure WebAssembly sandbox and a zero-latency IPC bridge. Your React code triggers an action, and OXP translates it to native IDE commands.
In VS Code, it binds directly to the native extension API.
In JetBrains, it uses JCEF to render as a native floating OS window.
You get blazing fast native speed from a single codebase.
**The Accidental MCP Fix:
While building this universal host layer, I realized OXP perfectly solves the current Model Context Protocol (MCP) configuration hell.
Instead of manually editing configurations for Cursor, Copilot, and JetBrains individually, OXP acts as a system level MCP router. If you run oxp install-mcp extension, the OXP daemon instantly wires that database context into the AI configurations of every detected IDE on your machine.
I'm opening up the infrastructure today. The CLI is live, and you can test it on your machine right now.
I'll be in the comments all day to talk about the WASM bridge, IPC latency, fighting with JCEF, and why extension silos need to die.
Building a Wasm-in-Wasm Virtualizer (with JIT decrypted paged memory)
trustsig.euJust as a privacy note (you can double-check with dev tools): This tool works fully offline, we do NOT send any uploaded binaries or data to our backend.
This tool was built by our WebAssembly analysis team, originally it was for internal use only but we have decided to make it public and free for everyone, forever.
Please do leave feedback in the comments! We'd love to hear what you think and how we can improve it even further. It is still heavily in a barebones beta phase, as we work on adding more features.
(This is not an advertising post for any paid or free services of TrustSig, this post is strictly to share the free tool we published and a blog post on how we made it)
Hexana started life as a plugin for JetBrains IDEs (IntelliJ IDEA, RustRover, WebStorm, GoLand, CLion, PyCharm, etc.) that treats .wasm and .wit as first-class IDE artifacts. It now also ships as a VS Code extension — version 0.0.2 just landed on Open VSX.
Install (VS Code command palette):
ext install JetBrains.hexana-wasm
Or from VSCode Marketplace: on VSCode Marketplace: https://marketplace.visualstudio.com/items?itemName=JetBrains.hexana-wasm or here: https://open-vsx.org/extension/JetBrains/hexana-wasm
Below: what's in the VS Code release on day one.
Custom binary editor for .wasm
Opens .wasm files in a dedicated read-only editor instead of the default VS Code hex view. The editor auto-detects whether the binary is a Core Wasm module, a Component Model binary, or a generic Wasm file. The structural analysis panel adjusts based on which kind it is.
Hex viewer
Virtual-scrolling hex dump. Byte selection via click, shift-click, drag. Keyboard navigation. Text search across the byte stream.
Structural analysis — up to 11 tabbed views
Surfaced based on the binary kind:
- Summary — section table + binary statistics
- Exports — kind, name, index, function signature
- Imports — kind, module, name
- Functions — index, name, signature
- Data — data segments
- Custom — custom sections
- Top — largest contributors by size
- Monos — monomorphisation analysis
- Garbage — unreferenced / dead code detection
- Modules — clickable nested-module drill-down (component model)
- WAT — WebAssembly Text rendered in a native VS Code editor tab with syntax highlighting
Every table sorts by column and supports text search.
Run support
Run a .wasm from the editor toolbar via wasmtime. The Run dialog asks which export to call and what program arguments to pass.
- Core modules → import stubs auto-generated.
- Component-Model binaries → dependencies resolved and composed before run.
Component Model
- Automatic dependency resolution by scanning workspace directories for matching
.wasmfiles, transitively. - Open a nested module inside a component binary in its own editor tab — same custom editor, full structural analysis.
Day-one scope
This is the day-one VS Code feature set. The JetBrains plugin has been around longer and currently has additional capabilities not yet in the VS Code extension — experimental WASM debugging (shipped in JetBrains 0.9, also out today), DWARF source mapping, WIT language support, JS↔Wasm type inference, Java embedder support (Chicory, GraalWasm), and additional runtimes for Run (WAMR, GraalVM).
If you need any of those today, the JetBrains plugin: https://plugins.jetbrains.com/plugin/29090-hexana
File issues if you hit something
If a .wasm should open and doesn't, or a section doesn't parse, the "doesn't load on this binary" reports are exactly what helps right now — ideally with a reproducer.
Install: ext install JetBrains.hexana-wasm
Web listing: https://open-vsx.org/extension/JetBrains/hexana-wasm
VSCode Marketplace: on VSCode Marketplace: https://marketplace.visualstudio.com/items?itemName=JetBrains.hexana-wasm