The terminal of the future

Original Article ↗ Hacker News Discussion ↗

Terminal vs Browser / Notebook / Editor

  • Many readers felt the described “future terminal” strongly resembles a web browser or Jupyter-style notebook: rich rendering, cells, visualizations.
  • Others argued browsers are heavyweight, centralized “middlemen” with huge complexity, while VT-style terminals are comparatively small and understandable.
  • Some questioned why, in a “next 200 years” series, the focus is on VT100-era protocols instead of HTML/CSS/JS, which already serve as a de facto cross‑platform UI standard.
  • Several distinguished between “text/command interfaces” (which people value) and “terminals” as a specific legacy implementation; the former need not be bound to VT semantics.

Backward Compatibility, Escape Sequences, and New Protocols

  • Strong concern about bolting ever more features onto VT220/ANSI: image protocols, truecolor, OSC/DCS extensions, etc., creating incompatibilities and breaking older/embedded/retro terminals.
  • Some advocated a clean side-channel for structured control data (e.g., JSON‑RPC or binary TLV over a pty or pipe) instead of escape-sequence hacks, with negotiation of supported features.
  • Others warned against JSON specifically (escaping, binary data, Unicode‑only), suggesting binary encodings (DER, SDSER) or protocol-agnostic side channels.
  • Persistent sessions already exist in tools like screen, tmux, Emacs, and some modern terminals; there’s surprise that terminal projects often reinvent features in isolation.

Structured Data vs Byte Streams

  • One camp insists the byte-stream model is the key to Unix composability: tools don’t need to agree on schemas; text pipes through grep/awk/sed “just work” across decades.
  • Another camp argues that this is fragile and forces everyone to write parsers; they point to PowerShell, Nushell, and JSON output as demonstrations of the power of self‑describing data.
  • Critics of object pipelines note brittleness (every stage must understand object types) and verbosity; defenders counter that Unix pipelines are equally dependent on correct assumptions about layout, just less explicit.

Alternative Visions and Existing Systems

  • Multiple comments note that much of the article’s wishlist already exists in:
    • Emacs (Org, REPLs, terminal emulators, programmable environment),
    • Acme and Plan 9’s “terminal as just a window,”
    • Arcan/Lash#Cat9 and Pipeworld (new TUI protocols, dataflow UIs),
    • Mathematica‑style notebooks, Pluto.jl, Marimo, Polyglot notebooks,
    • Experimental shells like Shelter and TopShell.
  • Some see attempts to “extend the terminal” as converging on these environments; others stress the difficulty of packaging such power in a way that “just works” for non‑enthusiasts.

Transactions, Runbooks, and History

  • Readers liked ideas around persistent sessions, runbooks, and editor‑centric workflows (sending code blocks to shells, structured history search).
  • There is skepticism about “transactional semantics” at the terminal level without OS‑level transactional storage; to some, this part of the proposal sounded hand‑wavy.

Attitudes Toward Modernization

  • A vocal group wants terminals kept simple and fast, viewing Jupyter‑like features, graphics, and RPC as bloat that undermines stability and long‑term compatibility.
  • Others think incremental tweaks won’t overcome decades of cruft and advocate bold, vertically integrated rethinks, even if that creates non‑portable ecosystems.
  • AI‑first terminals and agent‑driven futures are mentioned, but many expect Unix‑style terminals to persist for a long time, especially in conservative industries.