7 ms·
Browsh – A fully-modern text-based browser, rendering to TTY and browsers
- oefrha 4y agoSince 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 4y agoBasically 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=25129747 https://news.ycombinator.com/item?id=21630423 https://news.ycombinator.com/item?id=21630423 https://news.ycombinator.com/item?id=17487552 https://news.ycombinator.com/item?id=17487552
- ziftface 4y agoI 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.
- tombh 4y agoAuthor 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 4y ago> 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 4y agoThat'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 4y ago> 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 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.
- 3np 4y agoFor 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)?
- smitty1e 4y agoOne 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.
- deleted 4y ago[deleted]
- sylware 4y agoThey 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 4y agoYou'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 4y agoBe the change you want to see in the world.
- sylware 4y agoYep. 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 4y agoI 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.
- pbronez 4y agoVery 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 4y agoI must admit I've never used Gemini nor Gopher. Where do I start?
- gregsadetsky 4y agoI’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!
- tombh 4y agoWell 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 https://www.brow.sh/docs/in-browser-usage
- gregsadetsky 4y agoThanks 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 4y agoWow, that's really motivating to hear, thank so much :)
- rsecora 4y agoIt 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/ https://www.brow.sh/docs/introduction/
- dczx 4y agoHAProxy is a lifesaver
- capitainenemo 4y agoI'm kinda hoping he changes his mind on this one: https://github.com/browsh-org/browsh/issues/270 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 4y ago(for some comparisons here's chafa versus some block only based approaches https://m8y.org/tmp/console_images/ 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/catimg_min_font_size.jpeg https://m8y.org/tmp/console_images/chafa_min_font_size.jpeg https://m8y.org/tmp/console_images/chafa_min_font_size.jpeg
- mcdonje 4y agoMe 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."
- layer8 4y agoI wish there was a variable-width font equivalent of TUIs.
- tombh 4y agoHow do you mean? Like supporting emojis?
- layer8 4y agoI 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.
- lolpython 4y agoEmacs does provide that
- anthk 4y agoEmacs + Eww + custom elisp code to launch external tools for unsopported sites it's far lighter than this.
- justcodin 4y agoSeems very cool. Perhaps could be a way to, say, view stuff like StackOverflow on limited enviroments. Is there any way to run locally?
- tombh 4y agoHow 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.
- 1vuio0pswjnm7 4y ago"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.
- hedora 4y agoWhat text based web browsers do you recommend, and what sites still work reasonably well?
- gen220 4y ago`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 4y agoI 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.