This is really cool — the "try before install" problem is real for terminal apps.
I built a terminal collaboration tool and one of the hardest parts of getting my friends to try it is that they have to install a binary and set up tmux before they can even see what it looks like. A browser preview would completely change that.
Do you have plans for WebSocket support in the browser runtime? Would be interesting to see if real-time features (like live chat or presence indicators) could work in the browser version too.
Websockets would work great actually! Basically anything would work as long as you don't use any node or bun specific imports. For file systems you could also use something like this https://github.com/isomorphic-git/lightning-fs
I'm glad you think the try before install scenario makes sense - I think this is definitely the main use case.
You should be able to. We forked OpenTUI in order to avoid having to shim a bunch of native stuff. I'd like to make it compatible - email me at hi@cjroth.com if you find a way or want any help making it work
Cool I’ll try it out. I recently replaced xterm with Ghostty-web for my terminal in the browser app, but this looks even better. I’m using Next.js and I see you have an example.
Nice! I made a proof-of-concept of using Ink + Ghostty Web a few months back - we didn't end up merging it, but it's still an interesting thing that's possible. I think Ghostty Web is also has tons of potential.
> Gridland is the successor to Ink Web (ink-web.dev) which is the same concept, but using Ink + xterm.js. After building Ink Web, we continued experimenting and found that using OpenTUI and a canvas renderer performed better with less flickering and nearly instant load times.
Ah, I was wondering how this was different to xterm.js embedded in a page. It's just the performance angle? I've been teaching the kids programming from the terminal and I've been planning to make the jump from the terminal to a terminal in the browser as we hit graphical limitations (and as they want to be able to share their games). I'll take it for a spin.
(and if nothing else, I'm going to steal that ripple effect for them ;) )*
Yep, mainly performance - specifically page load time (near instant for Gridland vs ~2-3s for Ink Web). The other issue was flickering. Tbh rendering directly into a canvas is just a better approach and OpenTUI's architect is more modern.
I love that xkcd, I never know what to do, so I'll just ：）)
Can confirm good canvas renderer performance. Just tested it with a real-time smart meter dashboard — 62 meters streaming over MQTT via JustinX.ai (our data ingestion platform), 60 msg/s (peak), 500ms refresh. Almost no flicker, smooth updates across all meter cards. Much nicer way to handle high-frequency streaming data than xterm.js.
I love this. It needs to exist because it's fun.
Thank you! I'm glad you think so. It's all about fun.
This is really cool — the "try before install" problem is real for terminal apps.
I built a terminal collaboration tool and one of the hardest parts of getting my friends to try it is that they have to install a binary and set up tmux before they can even see what it looks like. A browser preview would completely change that.
Do you have plans for WebSocket support in the browser runtime? Would be interesting to see if real-time features (like live chat or presence indicators) could work in the browser version too.
Websockets would work great actually! Basically anything would work as long as you don't use any node or bun specific imports. For file systems you could also use something like this https://github.com/isomorphic-git/lightning-fs
I'm glad you think the try before install scenario makes sense - I think this is definitely the main use case.
Very nice
Could I use OpenTUI Core with this?
I'd like to replace the hero at https://blisswriter.app with the actual app
You should be able to. We forked OpenTUI in order to avoid having to shim a bunch of native stuff. I'd like to make it compatible - email me at hi@cjroth.com if you find a way or want any help making it work
Thanks. Will be a while before I could give this a shot...
Can I replace xterm.js with this?
Yes (if you're also down to use React)
Cool I’ll try it out. I recently replaced xterm with Ghostty-web for my terminal in the browser app, but this looks even better. I’m using Next.js and I see you have an example.
Nice! I made a proof-of-concept of using Ink + Ghostty Web a few months back - we didn't end up merging it, but it's still an interesting thing that's possible. I think Ghostty Web is also has tons of potential.
https://github.com/cjroth/ink-web/pull/1
> Gridland is the successor to Ink Web (ink-web.dev) which is the same concept, but using Ink + xterm.js. After building Ink Web, we continued experimenting and found that using OpenTUI and a canvas renderer performed better with less flickering and nearly instant load times.
Ah, I was wondering how this was different to xterm.js embedded in a page. It's just the performance angle? I've been teaching the kids programming from the terminal and I've been planning to make the jump from the terminal to a terminal in the browser as we hit graphical limitations (and as they want to be able to share their games). I'll take it for a spin.
(and if nothing else, I'm going to steal that ripple effect for them ;) )*
* obligatory https://xkcd.com/541/
Yep, mainly performance - specifically page load time (near instant for Gridland vs ~2-3s for Ink Web). The other issue was flickering. Tbh rendering directly into a canvas is just a better approach and OpenTUI's architect is more modern.
I love that xkcd, I never know what to do, so I'll just ：）)
Can confirm good canvas renderer performance. Just tested it with a real-time smart meter dashboard — 62 meters streaming over MQTT via JustinX.ai (our data ingestion platform), 60 msg/s (peak), 500ms refresh. Almost no flicker, smooth updates across all meter cards. Much nicer way to handle high-frequency streaming data than xterm.js.
Check out the video screen grab: https://streamable.com/hcga8t