IdeaWell

Project ideas from Hacker News discussions.

Building a TUI is easy now

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. Mobile keyboards and the “TUI‑mobile” problem
TUIs were designed for physical keyboards, not for the on‑screen keyboards that dominate phones.

“The thing with TUIs is that, using mobile native virtual keyboards, it’s apparently quite impossible to make them behave in a sane way in browsers!” – emilfihlman
“Mobile is not for TUI” – NetOpWibby

2. TUIs as a middle‑ground between CLI and GUI
Many users see TUIs as the best of both worlds: the speed and scriptability of a CLI with a richer interface than plain text.

“I want my interfacing with computers to be mouseless and TUIs offer that.” – 2muchtime
“TUIs hold a very nice spot between GUIs and CLI.” – verdverm

3. Modern libraries make building TUIs easier, but not trivial
The rise of frameworks like Charm, Ratatui, Textual, and BubbleTea has lowered the barrier, yet performance and usability still bite.

“Building a TUI is easy now” – tekawade
“I built this with the fantastic ghostty‑web project” – abelanger
“They’re not a TUI, that’s a CLI” – baq (highlighting the thin line between the two)

4. Constraints, accessibility, and performance trade‑offs
TUIs excel on low‑footprint, remote, and containerised environments, but they can suffer from discoverability, mouse support, and rendering overhead.

“TUIs automatically work over ssh, can be suspended with ctrl‑z and such” – sunshowers
“They flatten the structure of a UI under a character stream” – dwb
“The TUI feels like a real app as opposed to a glorified webpage.” – jxdxbx

These four themes capture the core of the discussion: mobile incompatibility, the niche role of TUIs, the tooling that makes them accessible, and the ongoing trade‑offs that keep them a specialized choice.

🚀 Project Ideas

MobileTUI

Summary

  • A lightweight, cross‑platform TUI framework that natively supports mobile virtual keyboards, touch gestures, and mouse‑like interactions in mobile browsers via WASM.
  • Solves the pain of “mobile is not for TUI” and “impossible to make them behave in a sane way in browsers” by providing a unified input model.

Details

Key Value
Target Audience Developers building terminal‑centric tools that need to run on phones, tablets, and desktop browsers.
Core Feature Automatic input mapping (keyboard, touch, mouse), adaptive layout, and WASM‑ready rendering engine.
Tech Stack Rust + Ratatui core, WebAssembly, JavaScript bridge, optional React wrapper for UI composition.
Difficulty Medium
Monetization Revenue‑ready: tiered subscription for enterprise support and plugin marketplace.

Notes

  • HN commenters lament “mobile is not for TUI” and “impossible to make them behave in a sane way in browsers” (emilfihlman, netOpWibby).
  • MobileTUI would let users run Termux‑style apps on iOS/Android without re‑implementing the UI.
  • The ability to embed the same TUI in a web page (as requested by emilfihlman) would spark discussion on the future of terminal UIs.

TUI‑to‑Web Bridge

Summary

  • A lightweight daemon that runs any existing TUI (ncurses, Ratatui, Textual, etc.) and streams its output to a web UI in real time, preserving mouse, keyboard, and accessibility features.
  • Addresses the frustration that “TUI is not for web” and “no real advantage of TUIs over web forms” by bridging the gap.

Details

Key Value
Target Audience DevOps, sysadmins, and developers who want to expose legacy TUIs to remote users via browsers.
Core Feature Terminal capture, WebSocket streaming, virtual terminal emulation, and optional React/Ink overlay for richer interactions.
Tech Stack Go (for daemon), WebSocket, xterm.js, optional Rust for performance, Docker for easy deployment.
Difficulty Medium
Monetization Revenue‑ready: SaaS hosting for enterprises, free open‑source core.

Notes

  • Users like “I want a stream, not a TUI” (liveoneggs) and “TUI over SSH is great” (baq) would appreciate a web‑accessible version.
  • The bridge would enable “both TUI and GUI” workflows (verdverm) and allow mobile browsers to interact with TUIs without re‑implementing them.

Pipeline‑TUI Toolkit

Summary

  • A library of reusable, composable TUI widgets (file picker, progress bar, interactive prompt, tree viewer) that can be invoked from shell scripts or pipelines, with a CLI wrapper that launches the widget only for the interactive step.
  • Solves the need for “tui file picker in the pipeline” and “interactive step in a script” pain points.

Details

Key Value
Target Audience Shell script authors, CI/CD pipeline designers, and power users who want minimal UI in a pipeline.
Core Feature Stateless widgets, JSON‑based configuration, and a tui-run CLI that spawns the widget and returns structured output.
Tech Stack Python (Textual) or Rust (Ratatui) for widget core, Bash/Python wrapper, JSON schema for config.
Difficulty Low
Monetization Hobby (open‑source) with optional paid support for enterprise pipelines.

Notes

  • “Having a tui file picker in the pipeline can be a powerful technique” (sophacles) and “interactive step where it makes sense” (1123581321) highlight the demand.
  • The toolkit would enable users to embed a TUI in a make or git hook without leaving the CLI.

AccessibleTUI

Summary

  • A wrapper library that adds semantic trees, screen‑reader support, and full keyboard navigation to existing TUI frameworks (ncurses, Ratatui, Textual).
  • Addresses the frustration that TUIs “flatten the structure” and lack accessibility, making them usable for visually impaired users.

Details

Key Value
Target Audience Accessibility engineers, developers of TUI tools, and users who rely on screen readers.
Core Feature Accessibility API integration (AT-SPI, NVDA), semantic role mapping, and focus management.
Tech Stack C/C++ for low‑level hooks, Python bindings for Textual, Rust for Ratatui, integration with AT-SPI.
Difficulty High
Monetization Revenue‑ready: licensing for enterprise TUI products, consulting services.

Notes

  • “The TUI flatten the structure… we need a structured UI” (dwb) and “screen readers need a different UI” (elevation) show the unmet need.
  • By exposing a structured tree, TUIs can be navigated by screen readers, opening the ecosystem to a broader audience and sparking discussion on inclusive design.

Read Later