Live data from Hacker News

Show HN: Gridland: make terminal apps that also run in the browser

gridland.io

11–16 of 16 posts

Re: Show HN: Gridland: make terminal apps that also run in the browser

#11
> 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/

Re: Show HN: Gridland: make terminal apps that also run in the browser

#12

> 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 program…

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 :))

Re: Show HN: Gridland: make terminal apps that also run in the browser

#13
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.

Re: Show HN: Gridland: make terminal apps that also run in the browser

#15

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…

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.

Re: Show HN: Gridland: make terminal apps that also run in the browser

#16

> 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 program…

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

Post reply on HN