Show HN: Term.everything – Run any GUI app in the terminal

Original Article ↗ Hacker News Discussion ↗

Overall reaction

  • Strongly positive response; many call it “insane” in a good way and praise the craftsmanship.
  • Several people admit they have no concrete need for it but love it as a delightful, borderline-useless hack that feels like “programming as art.”
  • Some suggest they’ll install it purely out of respect, to keep around “for that one weird time.”

Relation to other projects and protocols

  • Compared to Carbonyl, brow.sh, and similar browser-in-terminal tools; commenters note this goes much further by handling arbitrary GUI apps, not just the web.
  • Mention of older/adjacent ideas: aalib/mplayer, text-mode video, X11 tricks (Xvfb + xwd + sixel), and a historic GTK “cursed” theme that rendered widgets as text.
  • Some argue that this essentially re-invents remote desktop/X11, others counter that it’s more tightly integrated with the terminal and Wayland-era friendly.

Use cases envisioned

  • Remote GUI over SSH where VNC/RDP/X11 forwarding are impractical or blocked by firewalls.
  • Managing GUI apps in containers or on build machines and clusters (e.g., Firefox for kerberos auth, Hadoop UIs) from a terminal-only environment.
  • Running GUI tools from low-powered or constrained clients (including iPad via SSH; VS Code-on-iPad is explicitly discussed).
  • Possible testing harness for GUI apps without a full desktop environment.

Platforms, terminal support, and Wayland/X11

  • Works on both X11 and Wayland hosts; includes a custom Wayland compositor without libwayland dependency.
  • Uses terminal image protocols; note that kitty/iterm2-like protocols work but can be inefficient for high-frame-rate graphics.
  • macOS support is desired; discussion centers on using virtual-display or accessibility/VNC tricks, with mention of a private virtual display API.
  • Clarified that it’s “in the terminal,” not raw text mode, though some confusion about framebuffer/tty vs terminal emulator appears.

Performance, input, and limitations

  • Performance highly dependent on terminal resolution; low-res is fine, 4K makes fans spin.
  • Input is via stdin only: requires hacks for games (e.g., Doom) due to lack of key-up events and control-key conflicts, making continuous movement awkward.
  • Copy/paste is planned via Wayland data-device; GUI text will remain pixel-based, with OCR suggested but considered out of scope.
  • Skeptics question practicality versus simply using RDP/waypipe/etc., but even they often concede the hack value.