[HN Gopher] Browsh - A fully-modern text-based browser, renderin...
___________________________________________________________________
Browsh - A fully-modern text-based browser, rendering to TTY and
browsers
Author : tsujp
Score : 194 points
Date : 2022-05-24 09:42 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sylware wrote:
| 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.
| ziftface wrote:
| 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.
| octoberfranklin wrote:
| Be the change you want to see in the world.
| sylware wrote:
| 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.
| t-3 wrote:
| 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.
| mcdonje wrote:
| 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."
| justcodin wrote:
| Seems very cool. Perhaps could be a way to, say, view stuff like
| StackOverflow on limited enviroments. Is there any way to run
| locally?
| tombh wrote:
| 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.
| capitainenemo wrote:
| 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.
| capitainenemo wrote:
| (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
| layer8 wrote:
| I wish there was a variable-width font equivalent of TUIs.
| tombh wrote:
| How do you mean? Like supporting emojis?
| layer8 wrote:
| 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.
| jefurii wrote:
| I'm imagining programming Python using a variable-width
| font and _that_ makes my head hurt. :)
| tombh wrote:
| Oh yes, that makes sense. I wonder if anybody's ever
| attempted that before
| lolpython wrote:
| Emacs does provide that
| anthk wrote:
| Emacs + Eww + custom elisp code to launch external tools for
| unsopported sites it's far lighter than this.
| tombh wrote:
| 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.
| dmos62 wrote:
| > 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?
| tombh wrote:
| 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?
| dgl wrote:
| > 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.
| easrng wrote:
| WebRTC can also go over UDP.
| tombh wrote:
| Ah, that's what I feared, close but not close enough :/
| 3np wrote:
| 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)?
| tombh wrote:
| 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.
| dolmen wrote:
| Here is a naive implementation of (a subset of) the kitty
| image protocol in Go: https://github.com/dolmen-go/kittyimg
| mftb wrote:
| Well done, this is really cool.
| GekkePrutser wrote:
| Or this one which also supports sixel and iTerm
| protocols:
|
| https://github.com/BourgeoisBear/rasterm
| 3np wrote:
| 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)
| octoberfranklin wrote:
| Did you really just use "sixel" and "modern" in the same
| sentence?
| yjftsjthsd-h wrote:
| > 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?
| tombh wrote:
| 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.
| russellendicott wrote:
| 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
| tombh wrote:
| 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.
| russellendicott wrote:
| Lol, that's why it will never be a thing. I just want
| people to make more TUI's.
| tombh wrote:
| Well you've inspired me to make more TUIs!
| Levitating wrote:
| I've used browsh years ago and I was very impressed. Very cool
| software.
|
| I hope to see your plans work out, sounds awesome.
| justcodin wrote:
| i was looking at terminal browsers. Just what I wanted
| [deleted]
| 1vuio0pswjnm7 wrote:
| "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.
| jefurii wrote:
| 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.
| hedora wrote:
| What text based web browsers do you recommend, and what sites
| still work reasonably well?
| gen220 wrote:
| `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.
| 1vuio0pswjnm7 wrote:
| 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.
| pbronez wrote:
| 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.
| tombh wrote:
| I must admit I've never used Gemini nor Gopher. Where do I
| start?
| oefrha wrote:
| 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.
| forgotpwd16 wrote:
| 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
| ziftface wrote:
| 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.
| dczx wrote:
| HAProxy is a lifesaver
| smitty1e wrote:
| 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.
| gregsadetsky wrote:
| 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!
| colanderman wrote:
| 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.
| tombh wrote:
| 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
| gregsadetsky wrote:
| 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!
| tombh wrote:
| Wow, that's really motivating to hear, thank so much :)
| rsecora wrote:
| 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/
| gregsadetsky wrote:
| 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.
| userbinator wrote:
| 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.
| gregsadetsky wrote:
| 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
| anthk wrote:
| Better if you get the mercurial version:
|
| hg clone https://hg.dillo.org
|
| Also there's fork on github with mpv+youtube-dl support.
| chakkepolja wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-24 23:01 UTC)