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.

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

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

WebRTC can also go over UDP.

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

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.

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

Well you've inspired me to make more TUIs!

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

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.

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)

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

Or this one which also supports sixel and iTerm protocols:

https://github.com/BourgeoisBear/rasterm

Well done, this is really cool.

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

> 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?

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.

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

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

i was looking at terminal browsers. Just what I wanted

> 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?

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?

Basically it runs a headless Firefox with a web extension that converts visible DOM to TTY cells (think a lightweight VNC). The usecase is for it to run at some server and then connect to it through ssh or mosh so to conserve data usage. Previous discussions are on submitted links pointing to the homepage:

https://news.ycombinator.com/item?id=25129747

https://news.ycombinator.com/item?id=21630423

https://news.ycombinator.com/item?id=17487552

I think another big advantage would be battery life. Firefox drains my laptops battery, and even though safari is more efficient, it's still really bad for battery life if you have a bunch of tabs open.

Something like this would help with that a lot because you just need a lightweight terminal.

Since the primary use case of this happens on a server (that is to say, typically using a server IP), and it uses headless Firefox of all things, I’m having a chuckle imagining someone looking for buses, traffic lights or fire hydrants in the pixelated rendering.

I’m currently trying to port a browser (any browser) to an extremely light device - 16 Mb of RAM, ~200 Mhz. No standard/system library.

I’m curious to see how Browsh fares!

My first try at compiling NetSurf was met with failure (I was stumped by the build process)

Do people here have recommendations for super minimal browsers whose source source is specifically very portable / easy to adapt / easy to configure? Something where ripping out even the network internals (i.e. libcurl) and replacing it is easy-ish?

Thanks!

It will not run in 16Mb. It's a headless Firefox with an extension to render the DOM to text.

From the docs:

"When the CLI starts, it looks for a compatible browser (currently only Firefox) and starts it in headless mode...."

[1] https://www.brow.sh/docs/introduction/

For sure, I'm imagining running the headless Firefox on a different machine and porting the light CLI/tty browser to the small device.

That's actually the point of browsh -- you can ssh from anywhere to a (different) machine running the headless Firefox. The machine ssh'ing in doesn't need much except a terminal.

https://en.wikipedia.org/wiki/Arachne_(web_browser) is a possibility. Old graphical DOS browser (so, minimal library dependencies) which can run even on an 8086. Runs on Linux too, so there's an aspect of portability. Probably well behind modern web standards though, despite its recent update.

Well the whole point of Browsh is that you run it on a remote server and use other clients to access it. You can even access Browsh with plain curl using Browsh's HTTP server mode: https://www.brow.sh/docs/in-browser-usage

Thanks a lot -- running browsh locally just now was a real eye-opener. I had tried it before but forgot how amazing it is.

The monochrome mode is exactly what I'm looking for, and the documentation is extremely clear. I will definitely spend some time taking a stab at a port. Really really excited about it.

Will probably contact you with updates if I'm able to make some progress :-)

Thank you for this great work!

Wow, that's really motivating to hear, thank so much :)

Are you fine with text-only, or want graphics? Try Dillo.

16MB of RAM and 200MHz (x86) would be more than sufficient to run Windows 95 and Internet Explorer 3, which is a full GUI browser, so that's probably the level of functionality you'll end up achieving.

Thanks, it was pretty motivating to see Dillo compile pretty much out of the box! Kudos to Dillo for portability (the source code is from 2015 and I'm testing it on a relatively recent macOS...!)

The legwork to port it (its underlying FLTK toolkit, the socket-communicating daemons, openssl, etc.) looks a bit daunting however. I might consider it if nothing else works.

Thank you

Better if you get the mercurial version:

hg clone https://hg.dillo.org

Also there's fork on github with mpv+youtube-dl support.

Dillo is one thing I remember using.

There was a DOS one (arachne?) I couldn't try, And Links2 also has GUI but it's quite archaic.

I think you'd have better luck trying to compile NetSurf.

I'm kinda hoping he changes his mind on this one: https://github.com/browsh-org/browsh/issues/270

IMO the gains w/ chafa are pretty enormous. I find it enormously helpful with w3m where it is my default image handler these days.

(for some comparisons here's chafa versus some block only based approaches https://m8y.org/tmp/console_images/ ) - and those are 2 year old chafa code.

https://m8y.org/tmp/console_images/catimg_min_font_size.jpeg

https://m8y.org/tmp/console_images/chafa_min_font_size.jpeg

Me reading the HN title and looking at the example image on github after clicking the link: "This is dumb."

Me reading the "Why use Browsh?" statement: "Oh, I was completely wrong. This is actually brilliant."

"However, traditional text-based browsers lack JS and all other modern HTML5 support."

This is feature not a bug, as the saying goes. I have been using text-only browsers for over 30 years. Without CSS or Javascript, the ability of web design to delay, distract and annoy is greately reduced. I get a much more consistent experience across all websites. A simple HTML reader shifts the balance of power over the experience of reading a website toward the user. Javascript generally shifts the balance of power toward the website operator.

If I want to run Javascript on the command line, today there are many options, e.g., Deno.

Browsh is perfect for my use-case, in which I need to test web apps running on VMs behind an SSH gateway. I could use Splashtop or similar but Browsh is so much easier.

What text based web browsers do you recommend, and what sites still work reasonably well?

`lynx` is the benchmark. `lynx -vikeys` if you're a vim user for a slightly better learning slope.

Which websites work well? A decreasing number, unfortunately. However, most RSS readers give a decent enough text interface, so you can use your RSS feed as a kind of liason to the wider web.

It's mostly a matter of getting accustomed to different hotkeys and scrolling UX. But once you're there, it's no less efficient than a normal browser, arguably. If anything, the minimalism keeps you away from more, erm, distracting sites.

I do not use Lynx. I used it in the 1990s. I would never use it again. I use a program originally written at Charles University in Prague. I make changes to the source code to customise the program. I use several different versions. Choosing software programs is a matter of personal preference. The number of text-only browsers is relatively small so one can easily try all of them and decide for oneself. No recommendations needed.

The question of whether a website "works" does not make much sense with respect to a text-only browser becaus our only goal when using a text-only browser is to read text. "Works" seems to suggest CSS or Javascript must execute, that there are graphics, e.g., images or fonts, that must display, in order for the textual content to be readable. IME, this is almost never the case.

With the text-only browser I use there is never need for a webpage to "load" or to wait for some script to execute. The goal is to only read text, not to view graphical design. As such, the only question is whether the browser (a) renders the HTML and (b) whether the textual content of the website is visible when the HTML is rendered.

Regarding (a), IME, the number of websites that fail to render is so small I could count them on one hand, if I could even remember them. It almost never happens. The text-only browser I use is much more forgiving when rendering HTML than a popular graphical browser. The HTML can be very rudimentary, it can contain errors, and the page will still look great.

Regarding (b), IME, there are some websites that do not place their textual content in HTML tags. What web developers call "SPAs" are one example but there are others as well. Instead of placing text in HTML tags, the text is presented as either JSON or unformatted ASCII, e.g., with escaped newlines.

This JSON or unformatted ASCII may be contained in the webpage or, as is often the case with SPAs, it may be requested from another address sometimes called an "endpoint".

The website operator expects the public will choose a browser that runs Javascript, that she will enable Javascript and that she will consent to running the remote Javascript needed to transform the JSON or unformatted ASCII into HTML. The later is a task that is easily accomplished outside the browser, without the use of Javascript. But by enabling Javascript, e.g., just to read some text, the user also opens herself up to the use of Javascript to serve ads and track her online behaviour. Needless to say, with Javascript disabled, or with a text-only browser having no support for Javascript, advertising and tracking generally does not work. (This is the true context for the term "works" as applied to a website. Displaying text does not require Javascript, but ads and tracking do require Javascript.)

For this minority of websites referred to in (b), unless the text we are reading contains hyperlinks, a browser is not required because there is no HTML to render. We can use programs suited for reading/editing text, such as less(1), vi(1) or ed(1). Where the text contains some hyperlinks, we can create simple HTML according to our own aesthetics. Adding a single HTML tag at the top of the document, or wrapping paragraphs in <p> tags is usually enough for it to render as readable text in the text-only browser.

One good aspect of a headless modern browser is factoring out the need to stay current with the latest web standards.

Someone Else's Problem (SEP) is a beautiful thing.

Very cool.

Have you considered bundling support for tinyweb protocols like Gemini and Gopher? Those will work with full fidelity over the kinds of connections you’re focused on, and the core Browsh features allow you to jump from Gopherspace/ Geminispace to www without leaving the terminal.

Maybe the smart way to do this is to add Browsh as an optional dependency to a terminal-based Gemini client… the proxy architecture would add overhead if you run the whole thing locally though. I can see preferring to have a SSH connection from the client to a master proxy node that handles all protocols.

I must admit I've never used Gemini nor Gopher. Where do I start?

I wish there was a variable-width font equivalent of TUIs.

Emacs does provide that

Emacs + Eww + custom elisp code to launch external tools for unsopported sites it's far lighter than this.

How do you mean? Like supporting emojis?

I mean normal text being rendered with a variable-width font instead of as monospace, for better readability. When I was younger I didn’t care much, but as my eyesight is getting worse, monospace text is becoming more straining to read.

Rendering variable-width fonts in a TUI-like layout environment isn’t exactly straightforward obviously, but I’m sure it could be solved adequately. The point is to still retain the snappiness of TUIs by not going full GUI and by still limiting layout to the coarse textmode grid.

I'm imagining programming Python using a variable-width font and that makes my head hurt. :)

Oh yes, that makes sense. I wonder if anybody's ever attempted that before

Seems very cool. Perhaps could be a way to, say, view stuff like StackOverflow on limited enviroments. Is there any way to run locally?

How do you mean run locally? Like caching Stack pages?

At least, Browsh has a Docker image, so anywhere you can run `docker run browsh/browsh`, you can run Browsh.

HAProxy is a lifesaver

They missed the point.

noscript/basic (x)html browsers are not grotesquely and absurdely complex and massive (including their SDK) and though, can perform a good enough job for bazillions of services provided over the internet.

Namely, even if you have an army of coders with infinite time and code a lean and simple C (C89 with benign bits of C99/C11) "modern" web engine, it won't change the core of the problem.

You're right, but unfortunately that's not the world we live in. Those text based browsers don't work for a lot of websites.

I spent a few months earlier in the year entirely in the console using links as my browser, and it worked just as well, and in some ways better than firefox with js disabled (ie. lots of sites that give a blank page or cookie popups just work). My main issues that led to returning to X were with the OpenBSD console having some annoyances WRT UTF-8 in tmux and not being able to figure out how to use a smaller/higher resolution font.

Be the change you want to see in the world.

Yep. I am trying to do something, but I realized that it means dealing with ppl which are severely brain-washed, or 101 scammers (web planned obsolescence).

It won't happen peacefully, my guess is it requires strong regulation, at least for critical sites (like those from the administration).

One of the main issues is the corpo(state?)-sponsored hackers paid to sabotage the alternatives.