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.
Aren't terminals also called... terminal emulators? All modern terminals would be an approximation by this logic. Some approximate backwards compatibility with VT** spec more than others.
I don't mean to derail discussion about a cool project, but it still seems to imply xterm.js is somehow "improper" emulation (though I might be misreading it).
Terminal emulators are all approximations of terminals, regardless of the programming language.
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.
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.
This is awesome! I'm Syrus, from Wasmer. Would love to help you with this!
We are releasing soon a new version of wasmer-js, so it should be very easy to use it with webassembly.sh (note webassembly.sh and wasmer.sh share the same code)
Everything went smooth (just added a new comment on top of this thread for visibility!), only nit is that `convertEol` didn't work, so I had to manually convert `\n` to `\r\n`.
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?
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!
Search had been a blocker, but that's coming soon; beyond that not sure that there's any reason other than inertia. Alacritty is totally fine, but excited for the Ghostty focus on performance (obviously), and the font rendering stuff looks excellent (though TBD how much of that we can "just use" vs needing to copy-pasta)
i switched from alacritty -> ghostty, and occasionally use zed.
i can't recall why i made the transition (maybe just to try it out, and it became default?). i can't think of any practical consequences of this transition.
why do you care about whether zed uses alacritty or ghostty under the hood?
Kitty Graphics Protocol support and subtle font rendering differences between Ghostty and Alacritty that drive me nuts.
I have reported font rendering issues to Alacritty in the past and let's just say the developer was not exactly receptive to fixing them since they occur on macOS and not his preferred OS of Linux.
Ghostty is a terminal like iTerm. This compiles it so it runs in the browser directly, or browser-based environments like VS Code or the Hyper terminal. Without that you’d have to reimplement a whole terminal in JavaScript. Which is what people have been doing with via the xterm.js project. Naturally, there is effort and bugs that go into maintaining a clone/port like that. This lets you use the Ghostty terminal code directly - compiled to WebAssembly and with no other dependencies - as an API-compatible drop-in replacement
That actually pretty much is the ELI5. Its merely a different terminal that offers more features than iTerm2 and also runs on OSX.
Unless you actually need/want those features (which, although I am a terminal aficionado, I must admit are niche as fuck), pick whichever terminal makes you happy. Features that are important to some people are performance, Unicode support, and OS support.
You could argue whether or not it's a "feature", but one of the thing ghostty claims as an advantage is the out of the box configuration.
With no config at all, ghostty looks nicer than my alacritty setup. The rendering is just real nice. I could probably get alacritty to look as nice or nicer, but ghostty just worked this way with no config needed.
So you could consider aesthetics and rendering quality, and simplicity of setup both as features, which people may need/want (or not).
I wouldn't argue against that at all: OOBE is absolutely a feature.
Problem is, we don't all agree with what the OOBE should be. I, for example, always strip out menus, tabs, and other UI features. For me, the terminal that requires the least lines in the config file is probably going to be the winner (assuming no unfixable defects that effect me).
I also have ton of questions. Hopefully the author can add more documentation to ghostty. Right now I don't fully understand the use cases or how people may benefit from ghostty.
This runs in the browser, so it would allow you to connect to a server from your browser and render normal terminal commands in that environment
For instance if you're a cloud provider, and you want people to be able to "drop in a shell" on a machine, but make that available through the web, you could use this
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.
It's maybe possible. Custom shaders are OpenGL syntax so it'd require transforming them to something compatible with WebGL/WebGPU. In Ghostty GUI we use spire-cross and glslang to transpile shaders at runtime from OpenGL to Metal or OpenGL (with features our host supports).
We'd have to look and see if these support WebGL/GPU. The next problem would be making all that fit into the wasm blob.
Or, we may be able to skip most of this is the OpenGL syntax we use is already compatible. Then no transpiling necessary...
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
We can easily make a browser shell that let's people run basic commands, but presumably most want to try `vim` and other commands they'd typically invoke.
If you have a Dockerfile that bundles ghostty-web with a backend (even just `ttyd` or a simple socket server), I’d love to host the official demo for you. We can give it a dedicated isolated environment so people can run vim safely.
`npx @ghostty-web/demo@next` starts an HTTP server on `localhost:8080`, so you could just wrap a basic Dockerfile with NPM installed (and maybe a variety of fun Linux tooling, ala vim).
Feel free to shoot me an email: kyle@coder.com. I'll happily add it to the README.
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.
Aren't terminals also called... terminal emulators? All modern terminals would be an approximation by this logic. Some approximate backwards compatibility with VT** spec more than others.
Agreed. I removed "not a JavaScript approximation of one" from the README.
I don't mean to derail discussion about a cool project, but it still seems to imply xterm.js is somehow "improper" emulation (though I might be misreading it).
Terminal emulators are all approximations of terminals, regardless of the programming language.
They are approximations but Ghostty has intentional effort towards correctness, more than I've seen from other terminal emulators.
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.
Excellent work!
We spent little time on performance so far, this is more of a POC that will hopefully become a drop-in replacement for xterm.js over time.
I'll swap it over to the new RenderState API and post some benchmarks!
Many kudos to y'all, we were shocked how simple it was to hack this together.
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.
nice one kyle! you could add https://github.com/wasmerio/webassembly.sh and have a fully featured in browser shell with support for installing packages!
I'll do this for a much improved demo!
Currently you need the command-line to try it, which is an unfortunate UX.
This is awesome! I'm Syrus, from Wasmer. Would love to help you with this!
We are releasing soon a new version of wasmer-js, so it should be very easy to use it with webassembly.sh (note webassembly.sh and wasmer.sh share the same code)
https://github.com/wasmerio/wasmer-js/tree/main/examples/was...
Neat. I'll take a look. Thanks Syrus!
Everything went smooth (just added a new comment on top of this thread for visibility!), only nit is that `convertEol` didn't work, so I had to manually convert `\n` to `\r\n`.
I've set up an online demo using Wasmer for local execution, so everyone can try easily! (try typing `cowsay hello`):
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!)Just fyi, I get no output from "cowsay hello" or "ls", and I see a bunch of errors in the Chrome JS debugger.
Thanks for the feedback, just realized as well and pushed a fix! (it was because the wrong headers were set)
This is awesome, thank you!
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?
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!
So, could someone now make a Visual Studio Code (and specifically code-server) that has ghostty-web as the Terminal?
Yup, that's the idea!
Oh damn, this is awesome.
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.
We'd love to (and, tbh, likely will).
Search had been a blocker, but that's coming soon; beyond that not sure that there's any reason other than inertia. Alacritty is totally fine, but excited for the Ghostty focus on performance (obviously), and the font rendering stuff looks excellent (though TBD how much of that we can "just use" vs needing to copy-pasta)
Note search has landed in main, and the core of it is cross platform and exposed via libghostty (Zig API, C to follow).
Woohoo! Thank you!
(Edit) Download it here: https://github.com/ghostty-org/ghostty/releases/tag/tip
They could certainly compile Ghostty and link into it from Rust. I couldn't imagine it'd be that large of an undertaking.
i switched from alacritty -> ghostty, and occasionally use zed.
i can't recall why i made the transition (maybe just to try it out, and it became default?). i can't think of any practical consequences of this transition.
why do you care about whether zed uses alacritty or ghostty under the hood?
Kitty Graphics Protocol support and subtle font rendering differences between Ghostty and Alacritty that drive me nuts.
I have reported font rendering issues to Alacritty in the past and let's just say the developer was not exactly receptive to fixing them since they occur on macOS and not his preferred OS of Linux.
Hm, might try hacking this into https://tsl0922.github.io/ttyd/
Let me know if you encounter any issues! I'm working on performance benchmarks now.
I have no understanding of any of this except that Ghostty is an alternative to iTerm2. Can someone do a ELI5 for the uninitiated?
Ghostty is a terminal like iTerm. This compiles it so it runs in the browser directly, or browser-based environments like VS Code or the Hyper terminal. Without that you’d have to reimplement a whole terminal in JavaScript. Which is what people have been doing with via the xterm.js project. Naturally, there is effort and bugs that go into maintaining a clone/port like that. This lets you use the Ghostty terminal code directly - compiled to WebAssembly and with no other dependencies - as an API-compatible drop-in replacement
Only other relevant thing to add is that Ghostty is also written in zig and makes for a good showcase of the language.
That actually pretty much is the ELI5. Its merely a different terminal that offers more features than iTerm2 and also runs on OSX.
Unless you actually need/want those features (which, although I am a terminal aficionado, I must admit are niche as fuck), pick whichever terminal makes you happy. Features that are important to some people are performance, Unicode support, and OS support.
The most decidedly non-ELI5 feature comparison: https://www.jeffquast.com/post/state-of-terminal-emulation-2... and https://ucs-detect.readthedocs.io/results.html
You could argue whether or not it's a "feature", but one of the thing ghostty claims as an advantage is the out of the box configuration.
With no config at all, ghostty looks nicer than my alacritty setup. The rendering is just real nice. I could probably get alacritty to look as nice or nicer, but ghostty just worked this way with no config needed.
So you could consider aesthetics and rendering quality, and simplicity of setup both as features, which people may need/want (or not).
I wouldn't argue against that at all: OOBE is absolutely a feature.
Problem is, we don't all agree with what the OOBE should be. I, for example, always strip out menus, tabs, and other UI features. For me, the terminal that requires the least lines in the config file is probably going to be the winner (assuming no unfixable defects that effect me).
I also have ton of questions. Hopefully the author can add more documentation to ghostty. Right now I don't fully understand the use cases or how people may benefit from ghostty.
This runs in the browser, so it would allow you to connect to a server from your browser and render normal terminal commands in that environment
For instance if you're a cloud provider, and you want people to be able to "drop in a shell" on a machine, but make that available through the web, you could use this
Someone finally figured out how to make it work under Linux!
Not sure I understand :) it's certainly available in nixos https://github.com/NixOS/nixpkgs/blob/nixos-25.11/pkgs/by-na...
can you do a hosted demo with jslinux (or similar) as backend? https://bellard.org/jslinux/
Will do this!
I’ll add this as an option to my fork of gotty, currently uses xterm.js
This is fantastic. Under MIT even! Thank You!
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.
I'd have to let Mitchell answer this accurately.
Considering the native Ghostty does, I _think_ the answer would be yes? I might tinker around with this and let you know.
It's maybe possible. Custom shaders are OpenGL syntax so it'd require transforming them to something compatible with WebGL/WebGPU. In Ghostty GUI we use spire-cross and glslang to transpile shaders at runtime from OpenGL to Metal or OpenGL (with features our host supports).
We'd have to look and see if these support WebGL/GPU. The next problem would be making all that fit into the wasm blob.
Or, we may be able to skip most of this is the OpenGL syntax we use is already compatible. Then no transpiling necessary...
So now let's get ShaderGlass [1] and this to have a baby, so we can have cool-retro-term [2] in the browser.
[1] https://github.com/mausimus/ShaderGlass
[2] https://github.com/Swordfish90/cool-retro-term
Oh man this is awesome. Recently integrated xterm.js on a new project and was frustrated with the limitations. Great work!
Awesome. If you happen to integrate it and find any bugs, please give us a shout!
Do we have Windows support yet?
It should work! Our demo may not (as I haven't tested it, so don't want to advertise it).
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
No hosted demo?
It's tricky to do without a compute environment.
We can easily make a browser shell that let's people run basic commands, but presumably most want to try `vim` and other commands they'd typically invoke.
If you have a Dockerfile that bundles ghostty-web with a backend (even just `ttyd` or a simple socket server), I’d love to host the official demo for you. We can give it a dedicated isolated environment so people can run vim safely.
That would be great!
`npx @ghostty-web/demo@next` starts an HTTP server on `localhost:8080`, so you could just wrap a basic Dockerfile with NPM installed (and maybe a variety of fun Linux tooling, ala vim).
Feel free to shoot me an email: kyle@coder.com. I'll happily add it to the README.
Just emailed you! Demo: https://ghostty.ondis.co/
Added it to the README! Thanks again :)
Um, maybe Zork?
https://github.com/olson-dan/rustzork
but why?
See the comparison: https://github.com/coder/ghostty-web?tab=readme-ov-file#comp...
Ghostty has much better VT100 compatibility. It should have much better performance as well once we optimize.
Any chance that it can take advantage of webgpu, or is it already doing that from this wasm build?