News for hackers. Stuff that matters.
Re:Browsh – A fully-modern text-based browser, rendering to ... by 1vuio0pswjnm7 on Tuesday May 24, 2022 @10:18AM (#31492450)
"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.

Re:Browsh – A fully-modern text-based browser, rendering to ... by jefurii on Tuesday May 24, 2022 @12:13PM (#31493953)
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.
Re:Browsh – A fully-modern text-based browser, rendering to ... by hedora on Tuesday May 24, 2022 @11:03AM (#31493029)
What text based web browsers do you recommend, and what sites still work reasonably well?
Re:Browsh – A fully-modern text-based browser, rendering to ... by gen220 on Tuesday May 24, 2022 @12:19PM (#31494039)
`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.

Re:Browsh – A fully-modern text-based browser, rendering to ... by 1vuio0pswjnm7 on Tuesday May 24, 2022 @04:56PM (#31497462)
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.