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

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?

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

WebRTC can also go over UDP.

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.

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

i was looking at terminal browsers. Just what I wanted

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.

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.

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!

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.

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

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

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.

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

Be the change you want to see in the world.

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.