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

Original Article ↗ Hacker News Discussion ↗

Building rich text-based user interfaces in modern terminals is attracting interest but also exposes hard problems, from Unicode and emoji rendering quirks to performance, layout and accessibility for screen-reader users. Commenters debate the design of frameworks like Textual—which borrow ideas from web tech such as CSS and reactive state—versus simpler or more traditional TUI toolkits, and whether TUIs meaningfully compete with web GUIs. Many see TUIs as valuable for low-latency, SSH-friendly, keyboard-driven workflows and legacy-style business apps, while others question their practicality and commercial viability compared with graphical or browser-based interfaces.

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.