libghostty for WebAssembly got a lot of love recently and is now very, very, very good. I spent the day building harnesses and comparing to xterm.js and here are the results: faster at IO, faster at reflow, faster at rendering. Like, a lot a lot faster. We now provide pre-built `ghostty-vt.wasm` files in our GitHub releases. These are the fastest, most optimized builds that are compatible with every major browser going back a number of years. Before going over setups, I want to say that xterm.js is very good software. It is a relatively modern terminal, the maintainers are very nice, it's done incredible work for the web terminal ecosystem. I have nothing against them, but I'm in the business of making super fucking fast terminal emulators. Let me explain the setup in every case: IO throughput: This is an apples-to-apples comparison of `ghostty_terminal_vt_write` vs xterm's `Terminal.write(Uint8Array)` timed from first write to final completion callback. This is testing how fast a terminal emulator can process input and update internal state. Nothing else. Units are in MB/s processed. Note for graphemes: Ghostty has grapheme processing enabled and xterm.js does not (requires an addon). So, this shows how Ghostty does better despite having that cost. Column reflow throughput: Compares `ghostty_terminal_resize` to xterm's `Terminal.resize` with identical terminal states (same content, same size, same scrollback). The "dance" is rapid bigger/smaller resize of matching column widths, forcing text reflow. Units are in resizes/second. Render speeds: These test use the identical xterm.js WebGL renderer for both Ghostty and xterm.js. Since the renderer is identical, we can focus on how long it takes to prepare the inputs to the renderer (build the render state) and assert we get the same output byte-for-byte (since its the same renderer!). This is the truest way to measure these two because libghostty-vt itself does not provide a renderer, its about how long it takes to go from terminal state to render-ready. Full render: This tests a fresh renderer with nothing previously rendered. Units are in updates/second. Incremental render: This tests having prior state and only rendering specific changes such as adding scrollback, moving the viewport, moving the cursor. Units are in updates/second. This is using the latest released version of xterm in every case compared to the HEAD libghostty (since we haven't tagged a release, exact commit d760ee96e54657416eb427b793c7e839f003df7d).