[HN Gopher] Ghostty compiled to WASM with xterm.js API compatibi...
___________________________________________________________________
Ghostty compiled to WASM with xterm.js API compatibility
Author : kylecarbs
Score : 179 points
Date : 2025-12-01 18:17 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| someguy101010 wrote:
| 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!
| kylecarbs wrote:
| I'll do this for a much improved demo!
|
| Currently you need the command-line to try it, which is an
| unfortunate UX.
| syrusakbary wrote:
| 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...
| kylecarbs wrote:
| Neat. I'll take a look. Thanks Syrus!
| syrusakbary wrote:
| 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`.
| mitchellh wrote:
| 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!
| kylecarbs wrote:
| 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.
| VikingCoder wrote:
| So, could someone now make a Visual Studio Code (and specifically
| code-server) that has ghostty-web as the Terminal?
| kylecarbs wrote:
| Yup, that's the idea!
| indemnity wrote:
| 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.
| kylecarbs wrote:
| They could certainly compile Ghostty and link into it from
| Rust. I couldn't imagine it'd be that large of an undertaking.
| dfee wrote:
| 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?
| indemnity wrote:
| 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.
| cirwin wrote:
| 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)
| mitchellh wrote:
| Note search has landed in main, and the core of it is cross
| platform and exposed via libghostty (Zig API, C to follow).
| ivanjermakov wrote:
| No hosted demo?
| kylecarbs wrote:
| 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.
| gregsadetsky wrote:
| 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.
| kylecarbs wrote:
| 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.
| gregsadetsky wrote:
| Just emailed you! Demo: https://ghostty.ondis.co/
| kylecarbs wrote:
| Added it to the README! Thanks again :)
| VikingCoder wrote:
| Um, maybe Zork?
|
| https://github.com/olson-dan/rustzork
| jumploops wrote:
| Oh man this is awesome. Recently integrated xterm.js on a new
| project and was frustrated with the limitations. Great work!
| kylecarbs wrote:
| Awesome. If you happen to integrate it and find any bugs,
| please give us a shout!
| oersted wrote:
| 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.
| kylecarbs wrote:
| 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.
| mitchellh wrote:
| 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...
| VikingCoder wrote:
| 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
| pmarreck wrote:
| 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
| asadm wrote:
| can you do a hosted demo with jslinux (or similar) as backend?
| https://bellard.org/jslinux/
| kylecarbs wrote:
| Will do this!
| ghthor wrote:
| I'll add this as an option to my fork of gotty, currently
| uses xterm.js
| warunsl wrote:
| I have no understanding of any of this except that Ghostty is an
| alternative to iTerm2. Can someone do a ELI5 for the uninitiated?
| shevy-java wrote:
| 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.
| oulipo2 wrote:
| 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
| DiabloD3 wrote:
| 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
| bisby wrote:
| 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).
| DiabloD3 wrote:
| 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).
| nighthawk454 wrote:
| 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
| azemetre wrote:
| Only other relevant thing to add is that Ghostty is also
| written in zig and makes for a good showcase of the language.
| jordemort wrote:
| Hm, might try hacking this into https://tsl0922.github.io/ttyd/
| kylecarbs wrote:
| Let me know if you encounter any issues! I'm working on
| performance benchmarks now.
| sigmonsays wrote:
| but why?
| kylecarbs wrote:
| 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.
| ghthor wrote:
| Any chance that it can take advantage of webgpu, or is it
| already doing that from this wasm build?
| vadepaysa wrote:
| This is fantastic. Under MIT even! Thank You!
| shortlived wrote:
| Do we have Windows support yet?
| kylecarbs wrote:
| It should work! Our demo may not (as I haven't tested it, so
| don't want to advertise it).
| syrusakbary wrote:
| 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: npx @ghostty-web/demo@next
| # The preferred way # OR wasmer run wasmer/ghostty-
| web -> Go to http://localhost:8080/
|
| Source code: https://github.com/wasmerio/webassembly.sh (updated
| from xterm into ghostty-web without any issue!)
| kylecarbs wrote:
| This is awesome, thank you!
| thoughtfulchris wrote:
| 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!
| clintonc wrote:
| 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.
| solotronics wrote:
| 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?
___________________________________________________________________
(page generated 2025-12-01 23:00 UTC)