Things I've learned building a modern TUI Framework (2022)

Original Article ↗ Hacker News Discussion ↗

React-style design and CSS in Textual

  • Some see Textual as “trying to be React”: DOM-like tree, CSS-like styling, reactive attributes, component-style widgets.
  • Critics argue this leads to fragmented configuration (Python code + CSS) and non‑“Pythonic” multiplicity of ways to do things.
  • Others counter that trees, reactivity, and CSS are generic UI ideas, not React-specific, and that CSS is optional with Python equivalents for all styles.
  • Over time, Textual’s component set has grown, softening earlier complaints about missing widgets.

Motivations for and against TUIs

  • Pro‑TUI:
    • Work well over SSH; more responsive than remote GUIs (X, VNC, RDP) on high-latency links.
    • Keyboard-centric, low visual “fluff,” consistent hacker aesthetic, and simpler to build than full GUIs.
    • Good fit for developer tools, dashboards, and niche enterprise workflows (e.g., mainframe-style data entry).
  • Skeptical views:
    • Many users either want a minimal CLI or a full GUI/web app; TUIs feel niche or nostalgic.
    • Some argue GUI isn’t inherently heavier than TUI and that terminals are awkward for advanced interaction or graphics.

Unicode, emojis, and terminal limitations

  • Unicode width and emoji rendering are a recurring headache. Different terminals implement wcwidth/wcswidth inconsistently; ambiguous-width and compound emoji make alignment hard.
  • Some libraries restrict to a specific Unicode version or use heuristics; others suggest normalization or replacement (e.g., unidecode), with tradeoffs.
  • Mode 2027 and grapheme-aware terminals improve things but don’t fully solve cross-terminal inconsistencies.
  • Experiences show varied and often broken behavior for obscure Unicode symbols across terminals.

Accessibility and screen readers

  • Screen reader users report that animations and Unicode diagrams in TUIs can severely break accessibility.
  • Textual’s internal DOM could, in theory, expose richer structure to assistive tech, but no terminal protocol or standard exists today.
  • Proposals include new escape sequences or APIs akin to browser accessibility trees, but adoption would require changes across libraries, terminals, OS a11y APIs, and screen readers.

Performance, animation, and protocols

  • Discussion of “overwrite, don’t clear,” single-write frames, double-buffering, and synchronized output to avoid flicker.
  • Some claim 60 fps in terminals is “smooth enough”; others argue terminals remain fundamentally limited (cell-based motion, input latency, lack of true smooth scrolling).
  • Opinion sharply diverges on whether sophisticated animation belongs in terminals at all.

Tools, use cases, and alternatives

  • Reported Textual use cases: dictionaries, personal tracking, compilation-pipeline explorers.
  • Alternative TUI toolkits mentioned: FTXUI (C++), Rich (Python), Bubble Tea (Go), notcurses; terminal widgets like libvte and xterm.js.
  • Some question business viability of a TUI company, while others suggest monetizing migration/consulting and eventual web backends.