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!
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.
Terminal emulators are all approximations of terminals, regardless of the programming language.
When users reattach to their session we render the terminal state and output from ghostty. Super cool and works really well. It’s basically tmux-lite in 1k LoC
Maybe I’ll try the session name thing, I just foresee it being annoying. Do you see your tool as a shpool replacement?
I totally understand your concerns for creating new terminals for short tasks. I generally lean towards `nvim` terminal buffers to solve that issue. Or I have a `term` session open that I can quickly go to for random terminal commands that don't belong to a project.
Will try this out on my arch system later this week though.
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/
Currently you need the command-line to try it, which is an unfortunate UX.
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...
Have you seen container2wasm or ktock/vscode-container-wasm?
container2wasm: https://github.com/container2wasm/container2wasm
ktock/vscode-container-wasm: https://github.com/ktock/vscode-container-wasm
ktock/vscode-container-wasm-gcc-example: https://github.com/ktock/vscode-container-wasm-gcc-example
From joelseverin/linux-wasm: https://github.com/joelseverin/linux-wasm :
> Hint: Wasm lacks an MMU, meaning that Linux needs to be built in a NOMMU configuration. Wasm programs thus need to be built using -fPIC/-shared. Alternatively, existing Wasm programs can run together with a proxy that does syscalls towards the kernel. In such a case, each thread that wishes to independently execute syscalls should map to a thread in the proxy. The drawback of such an approach is that memory cannot be mapped and shared between processes. However, from a memory protection standpoint, this property could also be beneficial.
Would hardened_malloc or llvm scudo be useful in a WASM runtime (given that WASM doesn't have an MMU)? https://www.google.com/search?q=would+hardened_malloc+be+use...
Emscripten handles malloc and free with dlmalloc, emmalloc, mimalloc,
emcc your_code.c -s 'MALLOC="emmalloc"' -o your_code.html
"Import custom memory manager?" · Issue #24851 · emscripten-core/emscripten https://github.com/emscripten-core/emscripten/issues/24851
Just learned about Cage:
Cage does Hardware-Accelerated Safe WebAssembly (WASM) with LLVM with support for ARM64 Memory Tagging Extension (MTE) and Pointer Authentication (PAC) memory safety features.
"Cage: Hardware-Accelerated Safe WebAssembly" (2024) https://arxiv.org/abs/2408.11456v2
https://imgur.com/a/2vsGS0G
### Photo Log
| Filename | Description |
|----------|-------------|
| ClaudePOV_20251202_134349_2.png | First 720p test - VT100 terminal visible |
| ClaudePOV_20251202_143259_4.png | Inside hyperspace tunnel - green rings |
| ClaudePOV_20251202_143325_5.png | Tunnel with pink/purple shift |
| ClaudePOV_20251202_143432_6.png | BX-2100 silhouette, purple nebula |
| ClaudePOV_20251202_143655_7.png | BX-2100 close-up, cockpit visible |
The Remote Control API is just HTTP/JSON so Claude wrote some powershell scripts to query objects from the endpoint.
We gave Claude a Character Actor in game with an AI controller attached, and it can call functions to the AIController - MovetoXYZ(), Teleport(), TakeScreenshot() etc
Currently it uses Xterm.js - but I'll have to try swapping Xterm out for ghostty-web!
The nice thing about this is that you do not need an OS / backend of any kind - everything runs in the browser - similar to webcontainers but without even needing a container.
From "WebAssembly (WASM) arch support for the Linux kernel" (2025) https://news.ycombinator.com/item?id=45784329 :
> JupyterLite still lacks a Terminal e.g. with BusyBox Ash in WASM, with a file system integrated with the Jupyter-xeus kernel file system.
> This [joelseverin/linux-wasm] appears to load much more quickly than other Linux and I think even just bash in WASM demos I've seen.
Stellar work, Kyle! Cheers
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
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
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).
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).
It will be used to render ANSI inside opencode
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.
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)
(Edit) Download it here: https://github.com/ghostty-org/ghostty/releases/tag/tip
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?
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.
You can also play around with a real shared containerized machine here: https://ghostty.ondis.co/
Considering the native Ghostty does, I _think_ the answer would be yes? I might tinker around with this and let you know.
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...
# Use 17 for Ctrl, 18 for Alt, 91 or 224 for Meta, 0 for none.
- name: ui.key.accelKey
type: uint32_t
#ifdef XP_MACOSX
value: 224
#else
value: 17
#endif
// user.js
user_pref("ui.key.accelKey", 91);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.
`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.
Ghostty has much better VT100 compatibility. It should have much better performance as well once we optimize.
(Seems slightly better in the actual Ghostty app, but not in any usable way: here was my comparison last year https://shreevatsa.net/post/terminal-indic/ and Ghostty is comparable to the other terminal apps, better than some, worse than some. Anyway the fact that it works in Ghostty but not in ghostty-web casts doubt on “Ghostty's emulator is the same battle-tested code that runs the native Ghostty app”. Do you understand what is going on?)
Thank you for letting me know!