Holy shit Kyle. I had no idea you were working on this. This is amazing. Your patch is also very instructive on what you need me to do for you to make this more reasonable.
I'm guessing that performance of this relative to xterm right now isn't... the best, mainly because the way you're grabbing the viewport seems expensive. I'm curious though if you did any benchmarks?
One thing you probably really want to expose is the new RenderState API: https://github.com/ghostty-org/ghostty/blob/main/src/termina... You're doing per row line grabbing currently which is probably pretty slow. The RenderState API is stateful and produces the state necessary to create a high-performance, delta update renderer. It's what our production GPU renderers are now built on (but the API itself is compatible with any kind of renderer). It'd be better for you.
After all that, I'm very curious even at this rudimentary level what the performance on various benchmarks look like compared to xterm.js.
Does this version support custom GPU shaders? I have been looking for a command-line with cool-retro-term aesthetics that can run in the browser for a while.
omg! Seriously, wow. That was quick! Only just heard that Hashimoto libbed out his terminal the other day and remarked about how smart that was... And it made this possible
Does not appear to work under Firefox, getting a bunch of CORS-related errors (header ‘user-agent’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response) on the /graphql endpoint.
This is super cool! I'm close to releasing a project to make Ink work in the browser for building cross-platform terminal apps. (Ink is what Claude Code / Gemeni CLI use for rendering.)
Currently it uses Xterm.js - but I'll have to try swapping Xterm out for ghostty-web!
Curious to know what makes this "a proper VT100 implementation in the browser, not a JavaScript approximation of one" -- isn't Ghostty also an approximation, just implemented in a different language? Seems unnecessarily pejorative to me.
I always thought it would be interesting in backend systems to catch a certain exceptions and auto-generate a link to a shell. Given the proper authentication is implemented would this be a good tool to achieve that "remote debug" shell?
Ghostty is so great. Cross-platform but native on Mac and Linux. Core written in a cool random language, showing that you can have well-behaved Mac apps that aren’t just pure Swift / Objective C. Same great design no doubt helps here.
35 comments
[ 1294 ms ] story [ 980 ms ] threadI'm guessing that performance of this relative to xterm right now isn't... the best, mainly because the way you're grabbing the viewport seems expensive. I'm curious though if you did any benchmarks?
One thing you probably really want to expose is the new RenderState API: https://github.com/ghostty-org/ghostty/blob/main/src/termina... You're doing per row line grabbing currently which is probably pretty slow. The RenderState API is stateful and produces the state necessary to create a high-performance, delta update renderer. It's what our production GPU renderers are now built on (but the API itself is compatible with any kind of renderer). It'd be better for you.
After all that, I'm very curious even at this rudimentary level what the performance on various benchmarks look like compared to xterm.js.
Excellent work!
I wonder if https://github.com/zed-industries/zed/discussions/18129 is still accurate. Would love to be able to use Ghostty as my Zed terminal.
https://ghostty-web.wasmer.app/
How to try it locally:
Source code: https://github.com/wasmerio/webassembly.sh (updated from xterm into ghostty-web without any issue!)Currently it uses Xterm.js - but I'll have to try swapping Xterm out for ghostty-web!
https://ghostty.ondis.co/
Stellar work, Kyle! Cheers