I'll do this for a much improved demo!

Currently you need the command-line to try it, which is an unfortunate UX.

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.

Yup, that's the idea!

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?

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)

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.

Awesome. If you happen to integrate it and find any bugs, please give us a shout!

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.

Will do this!

Here's v86 running in your browser with ghostty-web: https://bow-wrinkle-13326.ondis.co/

You can also play around with a real shared containerized machine here: https://ghostty.ondis.co/

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

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

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

Let me know if you encounter any issues! I'm working on performance benchmarks now.

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.

It should work! Our demo may not (as I haven't tested it, so don't want to advertise it).

This is awesome, thank you!

Just fyi, I get no output from "cowsay hello" or "ls", and I see a bunch of errors in the Chrome JS debugger.

I got ghostty-web working with this and it is great. Unfortunately it seems I don't have enough karma to post a link to it. But it's ink-web on npm if you're interested!

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.

Agreed. I removed "not a JavaScript approximation of one" from the README.

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.

Not sure I understand :) it's certainly available in nixos https://github.com/NixOS/nixpkgs/blob/nixos-25.11/pkgs/by-na...

The only thing I want (on MacOS) is the ability to search for text within a winodw, like when I'm debugging a stack trace, and multi-tab support.

libghostty is stellar! I’m using it for my session persistence for terminal processes tool: https://github.com/neurosnap/zmx

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

Doesn't trigger keyboard popup on my iPhone in Safari. :(

You could use Firefox and then set the accelerator key to Super, changing all application bindings to use Super instead of Control. This is my setup and it’s great.

  # 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);

Thanks for being a user :)