Ghostty compiled to WASM with xterm.js API compatibility

Original Article ↗ Hacker News Discussion ↗

Integration and demos

  • Rapid collaboration with Wasmer led to a hosted “local shell in browser” demo and an npm/Wasmer-based local demo flow.
  • Other demos pair ghostty-web with v86 and containerized backends, and there’s intent to integrate with jslinux and similar systems.
  • Some demos initially had issues (no output, CORS errors, Firefox incompatibilities) but were quickly patched.

Performance and architecture

  • Current implementation is described as a proof of concept; performance work is still ahead.
  • The Ghostty maintainer recommends using the RenderState API instead of per-line grabs to enable efficient delta rendering similar to native GPU backends.
  • Benchmarks vs xterm.js are planned but not yet shared; performance is expected to improve significantly once optimized.

Comparison with xterm.js and correctness claims

  • The project aims to be an API-compatible drop-in replacement for xterm.js, leveraging Ghostty’s existing emulator compiled to WASM.
  • Initial README language implying xterm.js was an “approximation” was toned down after pushback; commenters stress that all terminal emulators are approximations.
  • Ghostty is positioned as more correctness-focused than many peers, especially around VT100 behavior.

Use cases and ecosystem integration

  • Strong interest in using ghostty-web as the terminal inside VS Code, code-server, ttyd, and similar tools.
  • People are experimenting with it as a backend for Ink-based UIs, BubbleTea TUIs, and session-persistence tools via libghostty.
  • Suggested as a basis for “drop-in web shells” for cloud providers or on-demand debug shells.

Features, UX, and rendering

  • Native Ghostty is praised for out-of-the-box aesthetics, font rendering quality, and performance focus, with new features like search and splits landing in main.
  • Some users want Ghostty as the terminal in editors (e.g., Zed) due to better font rendering and Kitty Graphics Protocol support.
  • There’s interest in custom GPU shaders and retro aesthetics in the browser; feasibility depends on translating Ghostty’s OpenGL-style shaders to WebGL/WebGPU.

Technical issues and limitations

  • Complex-script support (e.g., Devanagari) initially failed in ghostty-web despite claims; this was acknowledged as a WASM exposure bug and fixed on main.
  • Mobile input initially didn’t trigger soft keyboards; a PR added this.
  • Questions arise about WASM’s lack of MMU, allocator choices, hardened mallocs, and security tooling like Cage, but these remain mostly exploratory.

Overall sentiment

  • The thread is highly enthusiastic: people see ghostty-web as a powerful way to reuse a “real” terminal emulator in the browser instead of maintaining a separate JS implementation, while recognizing it’s early-stage and still maturing.