Text-based web browsers

Original Article ↗ Hacker News Discussion ↗

Limits of Text-Based Browsers on the Modern Web

  • Many commenters agree with the article’s conclusion: the modern web’s complexity (JS-heavy apps, SPAs, cookie banners, ads) makes pure text browsing increasingly futile.
  • Even “lite” or mobile versions of sites are often one click away from breaking in text mode.
  • Some argue the web could support simple text well but, in practice, consistently chooses not to.

Gemini Protocol vs Simple Web Content

  • Strong support from some for Gemini as a deliberately constrained, text-only protocol that guarantees linear, distraction-free reading.
  • Others push back: they prefer rich web content and believe better user agents and filtering are preferable to retreating into an “ascetic” medium.
  • A middle-ground view: publish to both web and Gemini; Gemtext → Markdown is easy, the reverse is lossy but doable.
  • Confusion between Gemini protocol and Google’s Gemini AI shows discoverability and naming problems.

Tools and Architectures: Offpunk, Dillo, chawan, browsh, edbrowse, carbonyl

  • Offpunk, Dillo, rdrview/Readability, and similar tools extract main article content, often outperforming graphical browsers for reading (no ads/popups/paywalls).
  • chawan and brow6el are praised as advanced TUI browsers with CSS/JS/image support; sixel and kitty protocols enable inline images in terminals.
  • browsh and carbonyl (Chromium-in-terminal) are valued on slow links (e.g., airplane wifi) and VPS/headless scenarios.
  • edbrowse gets special attention as a CLI browser/editor/mail/IRC/SQL client, highly scriptable and designed with accessibility in mind.

Use Cases and Practical Value

  • Text browsers remain useful on headless servers, during broken graphics/login situations, for quick on-box debugging, and for scraping.
  • Some prefer them for reading (RSS + text browser) and for Tor Browser’s “Safest” mode.
  • Others argue GUI browsers are essential for mainstream use and that OS vendors should prevent situations where text-mode rescue is needed.

Accessibility, Semantics, and Anti-User Patterns

  • Discussion on nav-before-content HTML structures: good for some workflows but confusing for screen readers; “skip to content” links help.
  • Questions about hiding JS-dependent features and use of <noscript>.
  • MDN is cited about <datalist> accessibility concerns; frustration expressed at inconsistent, buggy screen reader ecosystems.
  • Many see popovers/cookie banners as anti-user; claims that cookie popups are often legally unnecessary and widely mis-implemented.

Nostalgia and Alternative Futures

  • Some reminisce about using Lynx as a daily driver when HTML was simple and suggest the web missed an opportunity to stay text-compatible.
  • Others propose AI-driven “reader mode”/user agents that reinterpret complex pages into user-preferred, text-centric views.