kylecarbs

(joining very late to the thread, but for future readers)

Coder requires zero internet-access, many of our customers run entirely airgapped. We _currently_ create an HTTP tunnel for first-time users to their Coder instance for a smooth setup. This removes the need to expose their deployment for workspace infra (e.g. EC2 VMs) just to try it out.

We could communicate this more clearly in our UX, which I'll fix up!

This is the exact use-case Boo is made for!

Apologies, half of this indeed was. As I was iterating on the README this seemed apt, but I will refrain!

Cmux is a standalone terminal. Boo is a command-line similar to screen, backed by libghostty for terminal emulation.

Just published v0.5.13 which should fix this! It seems to be a path issue. Now boo falls back to tmpdir for storing sockets.

I'll take a look at this now. Thanks for reporting!

Fair. Adding a section for this now.

screen actually works the same way architecturally: it parses all output through its own built-in terminal emulator and redraws from that state on reattach. But that emulator is decades old and lags far behind what modern programs emit. Whatever it doesn't understand gets dropped or mangled on redraw. boo swaps that layer for libghostty-vt, Ghostty's VT core, so the saved state matches what your terminal would actually display, and terminal queries get answered while detached so TUIs don't hang unattended.

tmux is great, it was just never the model I wanted. I really liked screen's simplicity, sessions and a prefix key and nothing else to learn, and boo keeps exactly that.

Bun has completely changed my outlook on the JS ecosystem. Prior to Bun, there was little focus on performance. Now the entire space rallies around it.

Congrats to Jarred and the team!

Taking a look now - thanks!

I'll take a look - not sure what's going on. I'll remove it from the README for now since it's not working in the demos.

Thank you for letting me know!

Thanks for being a user :)

They are approximations but Ghostty has intentional effort towards correctness, more than I've seen from other terminal emulators.

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

This is awesome, thank you!

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

Added it to the README! Thanks again :)

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.

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

Will do this!

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: [email protected]. I'll happily add it to the README.

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.

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.

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

They could certainly compile Ghostty and link into it from Rust. I couldn't imagine it'd be that large of an undertaking.

Yup, that's the idea!

Neat. I'll take a look. Thanks Syrus!

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.

I'll do this for a much improved demo!

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