Plain text has been around for decades and it’s here to stay

Original Article ↗ Hacker News Discussion ↗

Plain text is portrayed as the enduring “lowest common denominator” of computing, valued for its simplicity, portability, and compatibility with tools like version control, editors, and command-line utilities. Commenters debate what “plain text” really means in 2026—ASCII vs Unicode, UTF‑8 vs UTF‑16, and how encoding complexity, structure (JSON, YAML, XML), and accessibility affect its usefulness—while also exploring text-based diagrams, TUIs, and plain-text accounting as practical success stories. At the same time, critics highlight its limits for images, rich layouts, and internationalization, arguing that overreliance on text can obscure better-suited graphical or binary formats for complex tasks.

Plain text, Unicode, and encodings

  • Debate over what “plain text” means:

    • Some equate it with ASCII only; others with Unicode text (usually UTF‑8); others use the cryptographic sense (any unencrypted data).
    • One view: Unicode is too complex and quirky to be “plain”; ASCII is the only truly universal baseline.
    • Counter‑view: today UTF‑8 is the de facto standard and “good enough,” giving back a meaningful notion of plain text.

  • Encoding issues:

    • Past pain with code pages, Shift‑JIS/EUC‑JP, and mojibake is cited as a reason to standardize on UTF‑8.
    • Others still prefer explicit encodings/BOMs and even code‑page‑like systems, arguing files are meaningless without a declared format anyway.

Size, efficiency, and tradeoffs

  • Some criticize UTF‑8 as space‑wasteful vs UTF‑16 or compact single‑byte encodings, especially for Cyrillic, Greek, and CJK.
  • Others present measurements where UTF‑16 only wins modestly for Japanese text and often loses once markup and compression are considered.
  • Consensus from many: small encoding gains rarely justify the interoperability costs of non‑UTF‑8 text.

Limits of plain text and structure

  • Plain text’s strengths: simplicity, tool ubiquity, longevity, easy parsing, and version control.
  • Limits noted: no native images/graphics, messy large configs, ambiguous grapheme clusters, RTL handling, and unreadability of unfamiliar scripts.
  • Some argue XML/JSON/YAML/Markdown/Org are “yes‑and” layers: still printable, but with defined structure.
  • Others point out formats like XML behave more like binary when you factor in encoding declarations and auto‑detection.

TUIs, terminals, and richer UIs

  • Strong enthusiasm for modern TUIs: perceived speed, consistency, low resource use, keyboard‑centric workflows, easy text selection/copying, and longevity.
  • Terminals now support layout primitives and even graphics protocols, blurring the GUI/TUI line.
  • Skeptics question rebuilding rich GUIs over terminals when we have abundant pixels and GPU power, especially for maps and images.
  • Ongoing tension between “constraint breeds good UX” vs “constraints limit what’s reasonable or possible.”

Plain‑text diagrams, plotting, and tools

  • Many tools are shared for ASCII/Unicode diagrams, box‑drawing, terminal plots, and Emacs modes.
  • Interest in hybrid text‑plus‑visual representations and concern about accessibility of ASCII diagrams for screen readers.

Plain text for personal data and accounting

  • Several describe successful use of plain‑text note systems, invoicing, and accounting (e.g., ledger‑style tools).
  • Benefits: no lock‑in, easy scripting, git history, timestamp attestation, and straightforward “escape plans” to other formats like CSV.