Browsh – A fully-modern text-based browser, rendering to TTY and browsers

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @06:50AM (#31490367)

Author here. I haven't done much with the code in about 3 years. But I still have lots of plans for it.

The big thing is I want to write my own UDP protocol for it. It'll be similar to MoSH's in the sense it's optimised for text, only sends diffs and supports network roaming. But it'll be different in the sense that Browsh is a _document_ viewer first and secondly a live-updating UI. Basically, you shouldn't have to wait for a roundtrip to scroll the contents of the page.

Then with this protocol, there can of course be multiple clients. Including JS in normal browsers! (I don't know how well UDP is supported in browsers, so maybe it falls back to TCP). I think I want Browsh to be mainly a text-based browser that actually runs in normal browsers. That might sound counter-intuitive, but recall that the Browsh server runs _remotely_, the actual downloading and native rendering of a webpage is done by Firefox/Chromium in a healthy datacentre in some big city.

Hopefully I can find a way to fund a nice big farm of Browsh servers to provide a free tier. With that and the JS client, you won't even need to download an app to use Browsh, just a few Kbs of JS in any normal browser.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by dgl on Tuesday May 24, 2022 @07:19AM (#31490574)

> The big thing is I want to write my own UDP protocol for it.

In theory WebTransport could solve both the problem of a UDP like transport (it deals with encryption and sessions as it's QUIC based, you could still do mosh like things inside it) and browser support... Sadly as https://web.dev/webtransport/#try-it-out says:

"The best way to experiment with WebTransport is to start up a compatible HTTP/3 server locally. (Unfortunately, a public reference server compatible with the latest specification is not currently available.)"

It's one of those things Google hasn't quite finished and it's unclear if they care enough to.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @07:43AM (#31490765)

Ah, that's what I feared, close but not close enough :/

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by easrng on Tuesday May 24, 2022 @08:59AM (#31491427)

WebRTC can also go over UDP.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by russellendicott on Tuesday May 24, 2022 @11:41AM (#31493540)

While what you're doing is much more appealing to mainstream as it interacts with real internet I wanted to share a loosely related PoC I've been working on for a terminal browser and custom gRPC protocol for serving terminal user interfaces over the wire.

See docs and gif demos here: http://uggly.bytester.net

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @12:08PM (#31493893)

This is amazing! So we could have an entire other internet based on your protocol? I'm definitely going to take inspiration from it, thank you.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by russellendicott on Tuesday May 24, 2022 @12:10PM (#31493912)

Lol, that's why it will never be a thing. I just want people to make more TUI's.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @03:20PM (#31496410)

Well you've inspired me to make more TUIs!

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by 3np on Tuesday May 24, 2022 @07:20AM (#31490585)

For the terminal use-case, what would your stance be on exploiting modern terminal functionality for e.g. high-res images (cf. kitty protocol, notcurses, sixels)?

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @07:42AM (#31490758)

I was for a long time against that, simply because it can't be represented as text. But now I understand that sixels are just more text-based ANSI escape codes! So I'm on board again, but I'm not so personally interested in it, so it's not a priority at the moment.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by 3np on Tuesday May 24, 2022 @07:50AM (#31490815)

In case you haven't seen, here's a fun demo of what's doable in modern terminals :)

https://piped.kavin.rocks/watch?v=dcjkezf1ARY

(This library specifically doesn't have nodejs bindings yet, though)

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by dolmen on Tuesday May 24, 2022 @07:52AM (#31490832)

Here is a naive implementation of (a subset of) the kitty image protocol in Go: https://github.com/dolmen-go/kittyimg

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by GekkePrutser on Tuesday May 24, 2022 @11:18AM (#31493235)

Or this one which also supports sixel and iTerm protocols:

https://github.com/BourgeoisBear/rasterm

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by mftb on Tuesday May 24, 2022 @09:13AM (#31491599)

Well done, this is really cool.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by octoberfranklin on Tuesday May 24, 2022 @08:18AM (#31491031)

Did you really just use "sixel" and "modern" in the same sentence?

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by yjftsjthsd-h on Tuesday May 24, 2022 @10:39AM (#31492724)

> The big thing is I want to write my own UDP protocol for it. It'll be similar to MoSH's in the sense it's optimised for text, only sends diffs and supports network roaming.

Why not just run it over mosh? What's the advantage to baking it into Browsh?

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @11:34AM (#31493454)

The best example is the scrolling one. MoSH scrolls the buffer on the _remote_ machine and tries to send the _UI_ diff. I want my protocol to send the whole document (or at least many pages worth of it), so that scrolling can be done locally, as you would expect with a normal browser. Browsh's protocol would still send diffs, but for JS-triggered changes to the _document_ (not the UI), like for new messages in a Slack chat, or a new email in an Inbox.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by Levitating on Tuesday May 24, 2022 @08:21AM (#31491050)

I've used browsh years ago and I was very impressed. Very cool software.

I hope to see your plans work out, sounds awesome.

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by justcodin on Tuesday May 24, 2022 @10:15AM (#31492397)

i was looking at terminal browsers. Just what I wanted

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by dmos62 on Tuesday May 24, 2022 @07:16AM (#31490561)

> you shouldn't have to wait for a roundtrip to scroll the contents of the page

I run into this when using a large (2k) mosh terminal. Scrolling through a file is painfully slow: it seems to redownload the whole screen, even though only a small number of lines are new. Any insight?

[ Parent | on HN ]

Re:Browsh – A fully-modern text-based browser, rendering to ... by tombh on Tuesday May 24, 2022 @07:24AM (#31490624)

That's exactly what I mean. It's annoying seeing as in theory the diff should have been small. But I guess it's just MoSH's algorithm not being quite clever enough. I wonder what can be learnt from video codecs in this respect?

[ Parent | on HN ]