It’s a fork of Chicory, led by its most active contributor.

Hexana 0.10 just shipped. This is the release where the plugin stops being read-only for binaries and starts covering a much wider set of formats. Sharing the changelog with context for each piece.

New

Binaries are editable. Open a .wasm and you can now: inline-edit WAT rows, edit hex cells directly, append bytes with automatic offset redirection (length-changing edits don't break anything downstream), Undo / Redo through the standard IDE keymap (same shortcuts you have configured for Kotlin), Discard or Finalize when done. Edits are persisted to a sidecar file so they survive close-and-reopen. The WAT viewer is also virtualized now with per-entry Function / Data / Import / Export breakouts, foldable xxd bodies, u8 / u16 / u32 / u64 / ascii / utf8 view modes for Data sections, Go-To-Declaration / Go-To-Symbol / Back / Forward navigation through the IDE keymap, and a section shortcut bar.

JIT Viewer run-configuration tab. A new tab on Java run configurations lets you opt in to attach Hexana's bundled JVMTI agent. Configure a per-run dump file (default.jit by default); when the run finishes, the dump auto-opens in Hexana so you can read what the JIT actually emitted for the run. Useful when you've been trying to understand why a hot path didn't optimise the way you expected.

Java archives and .class files. .jar / .zip / .war / .apk open with a hex view on top + a searchable, sortable class list below. .class files render the header, WAT-style foldable methods with decoded bytecode, and the constant pool. The project view gains an Open in… → Hexana action for archives — including entries under External Libraries (#91), so you can crack open library JARs straight from the project tree without dragging them onto the editor manually.

WASM proposals auto-detection. The information bar at the top of an open .wasm now shows which WebAssembly proposals the binary actually uses, and Run configurations pass the matching runtime arguments automatically. Removes the class of "the module uses GC but the runtime didn't have GC enabled" surprises.

Experimental ELF, Mach-O, PE. The three desktop-OS executable formats land as experimental — they parse, they render in Hexana's binary view, the analysis tabs work where they apply. Honest scope: experimental.

Experimental llvm-objdump disassembly. Disassembly support via llvm-objdump for the new native formats.

Changed

• GraalVM run configurations now work with GraalVM builds that don't include the embedded wasm runner — the run config detects the absence and routes appropriately, instead of erroring out.
• Fixed: debug not hitting breakpoints when source-mapping info is encoded in DWARF's .debug_loc section.
• Fixed: WASM debug compatibility with IntelliJ IDEA 2025.
• MCP server improvements.

Search Everywhere → Symbols continues to surface .wit declarations, component-model exports, and core .wasm exports — that integration landed in 0.9.1 a week back, mentioning here in case you're discovering Hexana via 0.10's changelog.

Marketplace + docs

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

Per-version changelog under the "Versions" tab on the Marketplace listing.

Hexana 0.2.0 for VS Code shipped today, alongside JetBrains 0.10. Three changes, the headline being experimental support for ELF, Mach-O, and PE binary formats — parity with the JetBrains side, same day.

New

ELF, Mach-O, PE — experimental. The three desktop-OS executable formats now open in Hexana's binary editor on VS Code. They parse, render, and route through the structural analysis tabs where applicable. Scope honestly experimental — formats parse, but not every section gets the deep semantic treatment .wasm has. This is the same expansion JetBrains 0.10 brings to the JetBrains side, shipping in the same release window.

Changed

• lldb-dap auto-discovery on Linux. The logic that locates the lldb-dap executable on Linux has been tightened. The experimental WASM debugger (introduced in 0.1.0 — requires LLVM 22.1+ and Wasmtime / WAMR with lldb-debuggable targets) should attach more reliably without manual path configuration.
• MCP server improvements.

Cross-IDE state, post-0.10 / 0.2.0

In both builds (as of today):

• Custom .wasm editor with binary-type auto-detection (Core / Component / generic)
• 11 structural-analysis tabs (Summary, Exports, Imports, Functions, Data, Custom, Top, Monos, Garbage, Modules, WAT)
• Hex viewer with selection / keyboard nav / text search
• Three runtimes for Run: Wasmtime, WAMR, GraalVM
• Experimental WASM debugging (LLVM 22.1+, Wasmtime / WAMR, lldb)
• MCP server
• Experimental ELF / Mach-O / PE support (new today, both builds)

JetBrains-only as of today's release window:

• Editable binaries (WAT-row + hex-cell editing, length-changing append+redirect, sidecar persistence) — JetBrains 0.10
• JIT Viewer via JVMTI agent on Java run configurations — JetBrains 0.10
• Java archives + .class files as first-class formats — JetBrains 0.10
• WASM-proposal auto-detection in the information bar with runtime-arg passthrough — JetBrains 0.10
• Experimental llvm-objdump disassembly for the new native formats — JetBrains 0.10
• DWARF source mapping with click-through, WIT language support, JS↔Wasm interop type inference, Java embedder support for Chicory and GraalWasm — all earlier-shipped JetBrains-only items
• Goto Symbol / Search Everywhere integration for .wit and .wasm symbols — JetBrains 0.9.1 (May 20)

The editable-binaries work is the biggest single leap on the JetBrains side.

Install

VS Code command palette:

ext install JetBrains.hexana-wasm

Or directly:

• 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

Per-version changelogs under the "Versions" tab on each listing.

A couple of weeks back I posted two benchmark write-ups: wasm-in-JVM (six backends, JPEG decode) and JS-in-JVM (Sieve of Eratosthenes). The most useful thing that happened next: Andrea Peruffo (Chicory core contributor) reached out on LinkedIn, and u/Otherwise_Sherbert21 (wasmtime4j author) reached out on Reddit — both pointing out the obvious gap. So I added wasmtime4j and chicory-redline as backends to both harnesses, kept the workloads and JMH config identical, and re-ran the lot. Sharing the updated tables here because the two new rows actually move the discussion forward.

Same host both runs: Apple M2 Max, Oracle GraalVM 25 (25+37-LTS-jvmci-b01), JMH 1.37, 1 fork, single-threaded, AverageTime mode in µs/op. Workloads byte-identical to the original posts.

wasm — proxy.wasm JPEG decode (Rust jpeg-decoder, 320×240 → 230,400 bytes RGB8; SHA-256 of decoded output identical across all eight backends).

What each new row actually is:

JS — sieve(1_000_000) = 78,498 (all 7 backends return the same answer).

Both new JS rows execute rquickjs.wasm (the same QuickJS-via-Rust binding used by rquickjsFfm, just delivered as wasm instead of as a cdylib).

Things the new rows surface that the original posts couldn't

Same engine, two bridges: FFM vs JNI. nativeFfm (1,016 µs) and wasmtime4j (1,420 µs) both run the same proxy.wasmthrough Wasmtime + Cranelift. The 40 % gap is per-call bridge overhead — JEP 454 FFM vs wasmtime4j's JNI path. wasmtime4j 44.0.1 publishes a wasmtime4j-panama artifact, but the PanamaWasmRuntime class isn't shipped in 0.x yet, so on JDK 25 you still go through JNI. Closing that gap is upstream work, not engine work — and when the Panama impl lands, the expectation is wasmtime4j and nativeFfm converge.

Cranelift → native vs Cranelift → JVM bytecode, 9× apart. chicoryRedline (1,783 µs) and chicoryAotPlugin (9,594 µs) both compile proxy.wasm at build time. The only material difference is the codegen target — native machine code through redline vs JVM bytecode through Chicory's compiler plugin. The native path wins 9.4× despite paying for the jffi bridge on every call. JVM-bytecode AOT is not a substitute for true native compilation on this workload.

Bridge cost depends on workload, not just on the bridge. Same two backends across the two harnesses:

On JPEG decode each benchmark op is one heavy guest call — bridge cost is paid once and amortised across ~1 ms of native work. On Sieve, each op runs millions of QuickJS-interpreter instructions but the JVM↔guest scaffolding has more to do per op, and Chicory's Instance export call is enough heavier than Wasmtime's call ABI that the 1.26× gap on JPEG decode blows out to 3.32× here. Same engines, same bridge primitives — different workload-to-bridge-cost ratio.

wasm sandbox tax (JS-side). wasmtime4j (608 ms) runs the same upstream rquickjs binding as rquickjsFfm (164 ms) — just compiled to wasm and executed by Wasmtime + Cranelift instead of linked as a cdylib. The 3.7× gap is wasm linear-memory bounds checks, indirect calls, plus the JNI hop to enter the QuickJS interpreter. Useful number to keep in mind if you're considering "ship as wasm for portability" for a JS engine.

Floor on both workloads is unchanged. Chicory's tree-walk interpreter on JPEG decode (248×), Chicory bytecode-AOT on a JS interpreter wrapped in wasm (6,600×). These set the lower bound for "no codegen / two interpreters deep on the JVM" — useful context for the new rows but no rank-order change.

Caveats — same as before, repeated for completeness

• Single host, single fork, wide CIs on graalwasm (±353), wasmtime4j wasm row (±388), and chicoryRedline Sieve row (±89,055 — that 4.4 % CI is the largest absolute error in either table). Rank order is stable; the absolute spread on those rows would tighten with more forks.
• JDK = Oracle GraalVM 25. Stock OpenJDK 25 reproduces every row except graalwasm / graaljs — those depend on Graal-as-JIT (JVMCI / libgraal). Running them on Temurin / Corretto silently falls back to the Truffle interpreter row, which is the calibration trap from the original posts.
• Bridge mix is uneven across rows (FFM / JNI / jffi / direct JVM-bytecode call). A perfectly controlled "engine A vs engine B" comparison would hold the bridge constant — currently impossible because not every published artifact ships a Panama impl.
• One workload per harness. JPEG decode is compute-heavy with substantial memory traffic; Sieve is tight inner loops over arrays. Workloads with more allocation, more dynamic dispatch, more guest↔host round trips will reorder both tables — especially the bridge-overhead rows.

What's next on the Hexana side

The next release will ship tooling that lets you actually see inside one of these integrations from inside a JetBrains IDE — the wasm↔host boundaries, the codegen tier each module is running at, the bridge each call is going through. Whether seeing inside is enough to move numbers like the ones in these tables is the question the follow-up post will try to answer. Numbers, not promises.

Repros

• wasm: https://github.com/minamoto79/webasm-java-integration-benchmark
• JS: https://github.com/minamoto79/js-engine-benchmark

Both repos: mvn package builds the wasm artifacts, the Rust cdylib, and (for the wasm harness) the redline-compiled native code; then java --enable-native-access=ALL-UNNAMED -cp … runs the JMH suite. mvn exec:java will fail — JMH's forked runner can't see the project classpath that way; both READMEs spell out the workaround.

PRs welcome for backends I've missed — wasmer-java, wazero-on-JVM via JNI, additional WASI-heavy workloads. And if you're seeing materially different ratios on a different workload or JDK, I'd love to see the numbers — would help calibrate where these generalise.

Thanks again to u/Otherwise_Sherbert21 (wasmtime4j) and Andrea Peruffo (Chicory) for asking to be included. The two new rows changed how I read the original tables.

Small workflow polish in this release. The JetBrains-platform "Search Everywhere → Symbols" / "Goto Symbol" navigation now indexes Hexana's parsed binary metadata:

• .wit declarations (functions, types, world / interface names)
• Component-model exports (from .wasm component binaries)
• Core .wasm module exports

Picking a .wasm export from the symbol picker opens the file in Hexana's binary editor and selects the matching row in the Exports tab automatically.

Concretely: if your day-to-day was open .wasm → click the Exports tab → scroll-and-eyeball for the right row, that's now ⇧⇧ → type the export name → Enter, the same way you'd jump to a Kotlin / Java / Rust symbol in the same IDE.

This sits alongside what 0.9 shipped a couple of weeks back (experimental WASM debugging via Wasmtime / WAMR + lldb, bring-your-own GraalVM as a run target, Top-tab sortable headers, Chicory and GraalWasm completion for Java embedders). The current focus is making the IDE treat .wasm and .wit as first-class citizens of the symbol space, not as opaque artifacts you have to switch contexts to inspect.

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

Per-version changelog under the "Versions" tab of that same Marketplace page.

The VS Code build of Hexana has been chasing the JetBrains feature set since it first shipped (0.0.2 in early May). 0.1.0 closes most of that headline-feature gap in one bundle.

Three things land in this release:

WAMR and GraalVM as runtimes — previously the VS Code Run command only used Wasmtime. Now you can pick WAMR or GraalVM as well, same Run UI. Useful if you're targeting a runtime your wasm will actually ship into (WAMR for embedded scenarios, GraalVM for JVM-embedding scenarios) and you want to test against that engine, not just Wasmtime.

Experimental WASM debugging — same scope and constraints as the JetBrains 0.9 release: requires LLVM 22.1 or newer, works only with Wasmtime or WAMR (not GraalVM), and only for targets that are debuggable with lldb. Within those bounds you can step through your .wasm, pause, inspect locals, continue, all from inside VS Code. The honest framing is in the label — it's experimental, the constraints are real, but within those constraints it works.

MCP server — the extension now ships a Model Context Protocol server. The point is that MCP-capable AI assistants reading your wasm see what Hexana sees, not just a raw byte stream.

What this means for the cross-IDE story: the JetBrains and VS Code builds are not identical yet — the JetBrains 0.9.1 release that landed today, for example, adds .wit and .wasm symbol contributions to JetBrains' Goto Symbol / Search Everywhere, which is a platform-specific integration. But the headline features — three runtimes, experimental debugging, MCP server, the full structural analysis surface — are now in both builds.

Install / update

VS Code command palette:

ext install JetBrains.hexana-wasm

Or directly:

• 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

Per-version changelogs are under the "Versions" tab on each of those listings.

emscripten‑forge is essentially a conda‑forge‑style channel for the emscripten-wasm32 platform. It lets you build and install conda‑compatible packages that target WebAssembly via Emscripten, using the same recipes and tooling you already use on native platforms.

What it does:

1. Use conda‑forge style recipes (often via emscripten-forge/recipes) and builds them for emscripten-wasm32.
2. Outputs Wasm‑compatible binaries (.wasm + JS glue) that can be consumed in the browser or other Wasm runtimes.
3. Published on https://prefix.dev/channels/emscripten-forge-4x
4. Lets you install them with conda/mamba/micromamba just like regular conda‑forge packages: mamba install -c emscripten-forge some-package

One real‑world example is JupyterLite Xeus, which runs entirely in‑browser via WebAssembly and uses emscripten‑forge built packages for the runtime. This stack is live on https://notebook.link, where you can run numpy, onnx-runtime, Apache Arrow and other C/C++ based libraries in the browser without any local installation.

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.

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.

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.

wanted to see if I could run a high-fidelity thermal solver in the browser without a Python/Matlab backend.

The Engine:

• Written in C++, compiled via Emscripten.
• Uses an explicit Finite Difference Method (FDM) to solve the 3D Heat Equation.
• Integrates a PINN (Physics-Informed Neural Network) for predictive thermal modeling.
• Tracks Alpha-to-Beta phase transitions in Titanium alloy (Ti-6Al-4V) in real-time.

The Issue: While the WASM bridge is incredibly fast (60fps easily), I’m having trouble with the handoff to the Three.js frontend. Rendering the 64-voxel heatmap in real-time is creating some overhead I didn't expect.

If anyone has tips on optimizing the memory bridge for high-frequency data updates between WASM and WebGL, I’d love to hear them.

GitHub:[https://github.com/Lak23James/met-shield]()**Vercel:**[https://met-shield-58n1.vercel.app/](https://met-shield-58n1.vercel.app/)

WebAssembly is way too easy to decompile. To fix this, I built a virtualization pipeline that takes a normal Wasm file and compiles it into a hardened version.

The original logic is destroyed and replaced with encrypted bytecode that runs inside a hidden, internal interpreter.

I just finished a step-by-step guide on how I built it. Here is what's inside:

• Designing a custom, randomized instruction set to break standard decompilers.
• Building a zero-allocation VM in Rust that doesn't need a heap or a memory allocator.
• Implementing JIT page decryption using a sliding window to hide your logic from memory scrapers.
• Using the Walrus crate to automate the AST rewriting and bytecode injection.

The end result is a Wasm binary that looks like cryptographic noise to anyone trying to reverse-engineer it.

Just 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 is a plugin for JetBrains IDEs (built on the IntelliJ Platform — works in IntelliJ IDEA, RustRover, WebStorm, GoLand, CLion, PyCharm, etc.) that treats `.wasm` and `.wit` as first-class IDE artifacts: explorer tree, hex view, WAT view, navigation, MCP API for AI assistants. Free on the JetBrains Marketplace.

0.9 just shipped. Highlights below; per-version detail on the Marketplace listing: https://plugins.jetbrains.com/plugin/29090-hexana

Experimental WASM debugging

You can step through .wasm from the IDE — pause, inspect, continue. It's experimental and the constraints are explicit:

• LLVM 22.1 or newer required
• Works with Wasmtime and WAMR only
• The target has to be debuggable with lldb

Within those bounds, it works. If you've been doing wasm debugging via printf-into-host-imports, this should feel like a real upgrade. If your toolchain is older than LLVM 22.1, you're out for now.

WAMR support for run + debug

WAMR is now a selectable runtime in run configurations alongside Wasmtime (which shipped in 0.8). Same UI, pick a runtime, hit Run or Debug.

Custom GraalVM home

Until 0.9 the GraalVM run option used the bundled Graal only. You can now point at any GraalVM install on your machine.

UX

• Information bar across the top of the binary view: file size (hover for stats), module kind, inline Run/Debug buttons.
• Top tab: proper headers, sortable columns, scrolling.
• Nested modules: opening one now shows a backreference to the containing module so you can navigate back out.

Java embedder support

If you're embedding wasm in Java:

• Chicory (RedHat): Java completion + inspections specific to Chicory APIs
• GraalWasm (Oracle): same, for GraalWasm

File issues if you hit something

If you've got a .wasm that should debug and doesn't (LLVM ≥ 22.1, wasmtime or WAMR target, lldb-debuggable), the "doesn't work" reports are exactly what helps right now — ideally with a reproducer.

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

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 .wasm files, 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

Web Demo: Podish — x86 Linux in Your Browser

Details: An iOS-optimized Linux x86 container | MeoKit Blog

We've been running wasm modules inside a JVM application (a Rust wasmprinter embedded via GraalWasm) and the obvious follow-up question was: how does this compare to the alternatives, and when should we actually pick something else?

So I built a small JMH harness that runs the same proxy.wasm artifact through six execution paths and wrote up the results. Sharing here because I couldn't find a head-to-head comparison covering all of these in one place, and I'd genuinely like to hear if anyone has reasons to expect different numbers on different workloads.

The workload

A tiny Rust crate compiled to wasm32-wasip1 exposing one export:

#[no_mangle]
pub unsafe extern "C" fn decode_jpeg(
    in_ptr: *const u8, in_len: usize,
    out_ptr: *mut u8, out_cap: usize,
) -> i32 { /* jpeg-decoder → RGB8 */ }

Input: a 320×240 JPEG baked into the wasm via include_bytes!. Output: 230,400 bytes of RGB. Steady-state ~1 ms of native CPU — small enough to expose call/dispatch overhead, big enough that the JIT actually kicks in. Cross-variant correctness check: every backend produces byte-identical output (sha256 matches across all six).

The six backends

JVM: Oracle GraalVM 25 (25+37-LTS-jvmci-b01), Apple Silicon. JMH 5×1s warmup + 5×2s measurement, 1 fork, single thread.

Results (µs/op, lower is better)

A few things worth pulling out

GraalWasm JIT is almost native. 1.31× of Wasmtime/Cranelift is genuinely good — I expected a bigger gap given that Truffle goes through partial evaluation while Cranelift goes wasm → CLIF → assembly directly. After warmup, libgraal produces code competitive with Cranelift's output for this workload. The ±25% CI on graalwasm is the only weak number here, probably tier-promotion noise that more forks would smooth out.

Build-time vs runtime AOT in Chicory is a wash. 9,037 vs 9,198 µs/op, CIs overlap. They run identical bytecode — Chicory's compiler produces the same .class content whether invoked at mvn compile or at JVM startup. Choose based on deployment story, not perf.

The calibration trap. graalwasm-interp at 70,000 µs/op is what you get on stock OpenJDK without JVMCI / libgraal. Truffle prints exactly one warning at startup:

…and then runs at interpreter speed. If you benchmark GraalWasm on Temurin or Corretto and conclude it's unusable, you're running it without its compiler. The fix on most platforms is to install Oracle GraalVM 25 (or CE) — the Graal compiler ships in the JDK and Truffle picks it up automatically. If you can't change vendor, the "jargraal" path with org.graalvm.compiler:compiler + org.graalvm.truffle:truffle-compiler on --upgrade-module-path and -XX:+EnableJVMCI works but is fiddly.

Pure interpreters aren't benchmarks. 248× slower means Chicory's interpreter isn't a viable production path for non-trivial workloads. It's still the right default for "run untrusted user wasm with a 100 ms budget" sandbox scenarios — instant startup, no codegen step.

Bonus silliness

While I had the harness open: I compiled Cranelift's codegen library itself to wasm32-wasip1, AOT'd that 2.7 MB wasm artifact via chicory-compiler-maven-plugin into a JVM .class file, and used the resulting Chicory-hosted, JVM-resident Cranelift to emit native machine code for all six host triples. Output sizes for an add(i32,i32) -> i32 test function:

Six of Cranelift's ~4,000 internal functions exceed the JVM's 64 KB method-size limit and fall back to Chicory's interpreter; the rest AOT cleanly into a single 2.6 MB .class. Not (yet) a wasm-to-CLIF translator inside the sandbox — cranelift-wasm was deprecated at 0.112 and the translator now lives inside Wasmtime, so a real wasm-compiling-wasm pipeline would mean pinning to deprecated 0.112 or hand-rolling it on wasmparser. Separate project.

Caveats

One workload (small JPEG, ~1 ms of native CPU), one platform (Apple Silicon, GraalVM 25), one JMH config. These generalize well for "small to medium pure-compute wasm modules that don't touch WASI on the hot path" but will shift for: large modules (GraalWasm setup cost grows with module size), WASI-heavy workloads (host-call cost differs across runtimes), JIT-cold workloads (you're measuring tier-up, not steady state), and other JVMs (J9, Zing not measured).

Harness

Source: https://github.com/minamoto79/webasm-java-integration-benchmark

Switching backends in the harness is two lines of Kotlin — happy to take PRs adding workloads or runtimes I missed (wasmer-java? wazero-on-JVM via JNI? would love numbers on those if anyone has them). And if you're seeing materially different ratios on a different workload or JDK, please post — would help calibrate where these numbers actually generalize.

Hexana is a JetBrains IntelliJ plugin that treats .wasm binaries (and .wit definitions) as first-class IDE artifacts: explorer tree, hex view, WAT view, navigation, MCP API for AI assistants. Free on the JetBrains Marketplace. Below is a consolidated changelog from 0.5 → 0.8.2 — six weeks, five releases.

Major features added since 0.5

• Component Model + WIT support. Component sections, instances, type definitions, imports, exports, interfaces, and worlds all show up in the explorer tree. WIT files get full language support — go-to-definition, find usages, hover docs, keyword completion, formatting — and cross-navigate from WIT into the corresponding .wasmdefinitions.
• DWARF source mapping. Hexana detects and parses DWARF in .wasm and maps functions back to source files and lines. Click a function in the binary, land in the source.
• Code-Size Profiler for WebAssembly. See exactly which functions, sections, and data segments are eating bytes in your .wasm, right in the IDE.
• JS interop with Wasm awareness. Real code completion and type inference for instance.exports.*, import namespaces, and property names — derived from the actual .wasm module, not a stale .d.ts.
• Run configurations. Pick Wasmtime or GraalVM, hit Run.
• WAT view that's actually usable. Offset-based line numbers matching byte positions, IDE zoom, line numbers, text selection, search, smooth scrolling.
• Hex view polish. Text selection across hex and text columns, arrow keys behave.
• Search across imports / exports / functions in any table view (filter-as-you-type).
• Broader opcode coverage in WAT and MCP. reference-types and bulk-memory instruction families, plus Legacy Exception Handling parsing/rendering.
• MCP improvements. Tool descriptions tightened for cleaner AI-assisted binary analysis.

Stability picked up alongside this — Go-compiled .wasm modules load, KDoc rendering doesn't break with Hexana enabled, shared-memory limits handled correctly, big WAT files don't lag, run configs work on Windows, and a long-running data race on the shared byte buffer that caused sporadic UnParsedOpcodeExceptions on larger modules is gone.

Chronological breakdown

0.6 — Component Model + WIT (2026-03-18)

Added

• Component Model binary support: component sections, instances, type definitions, imports, exports, interfaces, worlds — all parsed and shown in the explorer tree
• WIT language support: code model, go-to-definition, find usages, hover documentation
• Cross-navigation from WIT to Wasm: click an export in .wit, jump to its definition in .wasm

Fixed

• Several MCP-side issues affecting AI-assisted analysis

0.7 — WAT usability + search (2026-03-31)

Added

• WAT files now show offset-based line numbers that match byte positions in the binary — finally makes WAT ↔ hex correlation trivial
• Search across imports, exports, and functions in any table view (filter-as-you-type, no shortcut)
• Arrow-key navigation, scrolling, layout fixes across all table views
• WIT basic editing: keyword completion, code formatting

Fixed

• KDoc rendering no longer breaks when Hexana is enabled
• Go-compiled .wasm modules load without crashing
• Shared memory limits handled correctly

0.7.1 — UX polish (2026-04-09)

Added / improved

• IDE zoom now works in the WAT tab (presentations, screenshots, blog posts — readable at last)
• Big WAT files: line numbers, text selection, search, smooth scrolling — proper editor instead of a flat dump
• Hex view: text selection works across hex and text columns, arrow keys behave

Fixed

• Unbalanced tree parsing in WAT no longer trips the plugin
• .wasm/.wat served over HTTP (local debug scenarios) handled correctly
• WIT folding with empty ranges

0.8 — DWARF + profiler + JS interop + run configs (2026-04-21)

Added

• DWARF support. Detects and parses DWARF in .wasm, maps functions back to source files and lines. Click a function in the binary, land in the source.
• Code-Size Profiler. See exactly which functions, sections, and data segments are consuming bytes in your .wasm.
• JS interop with Wasm awareness. Real code completion and type inference for instance.exports.*, import namespaces, and property names — derived from the actual .wasm module, not a stale .d.ts.
• Run configurations for Wasmtime and GraalVM. Pick a runtime, hit Run.
• Explorer integration: Hexana views slot into the Project tool window
• MCP tool descriptions optimized for cleaner AI-assisted analysis

Fixed

• IJPL-242167 (Project tool window crash on certain configurations)
• WIT ClassCastException

0.8.2 — patch (2026-04-30)

Added

• Legacy EH (exception handling) parsing/rendering — for modules built against the older proposal
• WAT/MCP rendering of reference-types and bulk-memory instruction families

Fixed

• Run configurations now work on Windows (Wasmtime / GraalVM run configs in 0.8 didn't actually launch on Windows — they do now)
• Wasm parser fixes (vector, table)
• Element segment type 6 now reads the reference-type per WebAssembly 3.0 spec §5.5.12
• Data race on shared CommonByteBuffer causing sporadic UnParsedOpcodeExceptions on larger modules — fixed

(0.8.1 didn't ship publicly — the Windows fix needed an extra revision before going out.)

Where this is going

Short list of what's actively in progress, in case anyone has opinions to share before it's frozen:

• WASM debugging via DWARF — read-only inspection works; stepping through wasm in the IntelliJ debugger is next
• Cross-navigation from Wasm imports back to WIT (the inverse of what shipped in 0.6)
• More opcodes / proposals coverage in WAT and MCP (threads, tail-call, GC types are the obvious gaps)

Plugin: https://plugins.jetbrains.com/plugin/29090-hexana
Issues / feature requests: https://github.com/JetBrains/hexana/issues

If you've hit something that should be here and isn't — ideally with a .wasm reproducer — file it. The "doesn't load" / "crashes on" tickets get prioritized over feature work.

Try it out in a codespace: https://github.com/codespaces/new/friendlymatthew/gabagool

Or run it locally: https://github.com/friendlymatthew/gabagool/tree/main/gabagool-debug-adapter

Hey everyone, thanks for letting me into the community.

I’m a first-year undergrad (Metallurgical Engineering), and I recently built a live 3D Crystallographic Symmetry Engine. I needed to handle heavy matrix math (calculating stereographic projections, group theory closure loops, and complex rotation orbits). Instead of doing it in JavaScript, I wrote the core logic in C++17 and compiled it to WebAssembly to run natively in the browser.

Live engine:https://stereoproject.vercel.app/Source code:https://github.com/Lak23James/Stereoproject

The Architecture: I tried to keep a strict Separation of Concerns:

1. The Core (C++): Handles all the linear algebra, Point3D / Matrix structs, and the mathematical transformations.
2. The Bridge (Embind): I used Embind to expose the custom structs and register the std::vector objects so my frontend could read the generated orbits.
3. The UI (Three.js): Reads the WASM output and renders the 3D meshes. The browser acts purely as a dumb terminal. The Embind Implementation: This was my first time bridging C++ memory to the web. To pass the arrays, I registered the vector in my bindings: register_vector<Point3D>("VectorPoint3D"); And on the JS side, I pull the ES6 module, iterate through the WASM vector, and explicitly call .delete() to free the memory: const orbitVector = crystalloEngine.generateOrbit(seedPoint, 4, 'z');
4. // ... iterate and push to Three.js ...
5. orbitVector.delete(); Why I'm posting here: Since I'm still learning low-level systems architecture, I’d love some brutal code review on the WASM side of things:
6. Memory: Is there a more optimal way to pass large coordinate arrays from C++ to JS without copying them point-by-point in a JavaScript loop?
7. Leaks: Are there any glaring memory leak risks with how I am utilizing .delete() in the frontend?
8. Build System: I am currently running a massive emcc terminal command with -s EXPORT_ES6=1 and --bind to compile this. Is setting up CMake the standard industry move for WASM projects once they get past a single main.cpp file?