I explored this over the weekend and this is mostly just a knowledge dump from that, no promises around further investigation any time soon.

Ghostty has become quite good at this point. And while our parser is awesome, it's so good that AFAICT it's hit some hard limits around what's possible in JS. We could cut down the scope of the project by leveraging ghostty for one of the hottest paths while focusing xterm.js on the rendering, input handling, features like decorations, etc.

I've only dabbled with Zig, but as far as I can tell, the current libghostty-vt's scope seems quite slim and only does a subset of what EscapeSequenceParser.ts does currently. Here's the API. Some early explorations like ghostty-web and restty extend ghostty to expose the buffer from the core library as well, I think in order for it to be useful for us we would need something similar:

1. The parser API for feeding input into the parser and getting events out of it.
2. The entire buffer management system and the ability to pull lines, cells, etc. out of it. If we had this it's unclear if we would need to get events out of the parser API at all, we just need the ability to pull a bunch of state for things like modes, cursor position, etc.

With only 1 it's unclear if there would be any performance boost at all, but we would potentially get some additional functionality like kitty graphics parsing for free (cc @anthonykim1). With 2 we would be able to essentially replace Buffer.ts, BufferLine.ts, EscapeSequenceParser.ts and InputHandler.ts.

Positives:

• Leverage a set of passionate experts to handle these tough problems and likely better standards compliance/unicode support
• Squeeze out more throughput performance (not that xterm.js needs that). The overhead between the js context and wasm is likely not that large especially if care is taken around what data is transferred
• Some improved handling of certain cases that will likely not get handled properly otherwise due to time constraints like rtl, tmux control mode, etc.
• Reduce the scope of the library so more focus can be spent on other parts
• We can likely maintain full API compatibility, including things like decorations and the overview ruler

Downsides:

• Lose some control
• Makes debugging those parts harder
• I'm sure there will be a bunch of regressions just by moving this over
• Move the industry closer towards a monoculture (can be good and bad)

Unknowns:

• How far along ghostty is in exposing such an API.
• It's unclear whether using ghostty will cause problems with our parser handler API which is critical for certain functionality like shell integration in vscode, sixel/iip in addon-image, etc.
• If there will be problems around Windows support, which is the most important platform for VS Code.
• I don't know what ghostty's end game is, if they want to ship a library similar to xterm.js then it may not be worth pursuing this.

Explorations:

• Vibe coded adoption example: https://github.com/Tyriar/xterm.js/tree/ghostty_1 and https://github.com/Tyriar/ghostty/tree/xtermjs_1. I'm pretty certain there's a whole lot wrong with this prototype, but it didn't take long to put together and demonstrates how the parser works, interfacing with wasm, etc. The performance of this seems to be similar to the current parser, despite the fact that the input stream is being translated manually from UTF8 to UTF32, the slow DataView is being used to read events, doubling up some work, etc.

Related discussions:

• Use Ghostty as the Visual Studio Code terminal ghostty-org/ghostty#8800
• Ghostty as replacement to Xterm microsoft/vscode#236991

cc @jerch @mitchellh