wterm: A Smarter Web Terminal or Too Soon to Tell?

Xterm.js has been the default web terminal for over a decade. GitHub Codespaces uses it. Portainer uses it. VS Code uses it. When a technology achieves that kind of ubiquity, it stops being evaluated and starts being assumed — which is exactly when a credible alternative becomes interesting.

wterm, a web-based terminal emulator whose project page lists it at wterm.dev, is that alternative. Whether it's ready to act on is a different question.

The problem it's actually solving

To understand what wterm does differently, you have to understand what xterm.js does that has always been awkward. Xterm renders its output to an HTML canvas element. That means the terminal is, from the browser's perspective, a picture — not text. Every feature that browsers give you for free with real text has to be rebuilt from scratch on top of that canvas. Text selection. Find in page. Screen reader support. Copy-paste. Ten years in, xterm still hasn't fully solved these.

The Better Stack review puts it plainly: "xterm has a big problem — it renders to a canvas element. So doing something like selecting text or finding words in a page all have to be re-implemented from scratch, which doesn't always work that well."

wterm takes the opposite approach. It renders terminal output directly to the DOM as HTML. The browser then handles text selection, find, copy-paste, and screen readers natively — no reimplementation required. For anyone who has ever watched a screen reader user try to navigate a canvas-based terminal, that sentence carries real weight.

The engineering behind this matters too. wterm's core is written in Zig and compiles to a 12KB WebAssembly binary — a figure cited in wterm's own project materials. At that size, it's not parsing your escape sequences in JavaScript; it's doing the heavy lifting in Wasm while keeping the footprint small enough that it doesn't fight for bandwidth with the rest of your application. Critically, the Zig core only re-renders rows that have actually changed, rather than repainting the entire terminal on every frame. For something like htop — constantly updating partial rows — that efficiency matters.

What the Better Stack test actually tells us

The Better Stack reviewer built a working demo: wterm on a React frontend, a WebSocket server spawning a pseudo-terminal on a headless Ubuntu instance, keystrokes routed from browser to server and output routed back. The architecture is straightforward — the same one any team would use — and it worked. File navigation, vim, container listings, all functional.

But "functional" and "production-ready" are not the same shelf.

With the default Zig core, the reviewer found text selection problems: highlighted characters that became unreadable. The fix is the optional Ghostty-powered backend — a substantially larger WASM binary that swaps in libghostty, the same rendering engine behind the Ghostty native terminal. With Ghostty active, text selection worked correctly, color rendering improved, and tools like OpenCode rendered as intended.

The Ghostty backend also surfaced its own issues. The reviewer documented rendering glitches when switching between Neovim and other applications. There was also a build environment friction worth naming specifically: Bun, which is gaining real traction as a JavaScript runtime and bundler, wouldn't automatically copy the Ghostty WASM file from node_modules because Bun's asset handling only covers JS files by default. The reviewer had to import the WASM file manually to work around it.

That's not a footnote. A significant number of teams evaluating wterm today will be using Bun or will adopt it within the next 12 months. If setup requires manual WASM handling for Bun users, that's a documentation gap that becomes a support burden in production. It's the kind of friction that doesn't surface in a 6-minute demo but costs real hours during an integration sprint. Teams on Bun should budget for it; teams on Node will have a smoother path.

How ready is it, specifically

My read: wterm is 12 to 18 months from being the obvious choice for greenfield projects. Here's why that range, not six months.

The Zig core has a known text-selection defect that requires the Ghostty backend to resolve. The Ghostty backend has documented rendering edge cases in complex terminal applications. The Bun friction is unresolved at the toolchain level. None of these are fundamental problems with the architecture — the DOM rendering approach is sound, and the performance model is smart — but they're the kind of rough edges that get filed as "known issues" and take multiple release cycles to close.

If you're building a new cloud IDE, a browser-based SSH tool, or an infrastructure dashboard today, the DOM rendering advantage is real and immediate: accessibility compliance without a custom implementation, native browser search that actually works, screen reader support that doesn't require a workaround. Those are concrete wins you'd be leaving on the table by defaulting to xterm.js. For that use case, wterm is worth integrating now, with eyes open to the edge cases.

If you're maintaining an existing xterm.js integration, the calculus is different. You've already paid the accessibility debt in custom code, your team knows the xterm API, and the ecosystem around xterm — plugins, documentation, Stack Overflow answers — is deep. Migrating for the sake of migrating makes no sense until wterm's Ghostty backend stabilizes.

The xterm.js comparison deserves honesty

The Better Stack reviewer ends with something that reads like a concession but is actually the right framing: "Xterm.js does have a massive ecosystem and is the battle-tested solution, so you won't go wrong if you do end up choosing it."

That's correct. xterm.js isn't broken. It has a structural limitation — the canvas rendering model — that creates persistent friction around accessibility and native browser features. But it has also been running in production for years at a scale that wterm hasn't approached yet. The question isn't whether xterm.js has problems. It does. The question is whether those problems are expensive enough, in your specific context, to justify adopting a library that is still working out its own.

For accessibility-first applications, the answer skews toward wterm. For everything else, give it a year.

The DOM rendering idea isn't new — browsers have always been better at text than at canvas pixels — but wterm is the first project to build a serious terminal emulator on that principle rather than retrofitting accessibility onto a canvas approach after the fact. That distinction matters. It means wterm's accessibility isn't a layer; it's the architecture. When the rough edges are resolved, that will be harder to argue with than any benchmark.

---

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG