Why TUIs are back

Source: Hacker News

# Terminal User Interfaces (TUIs) are making a comeback

DHH’s [Omarchy](https://omarchy.org) is made of three types of user interfaces:

* **TUIs** – for immediate feedback and bonus geek points  
* **Webapps** – because 37signals (his company) sells SaaS web applications  
* **Native applications** – the unavoidable GNOME‑style apps that don’t fit well in the distro’s style  

![Omarchy distro](https://mundobytes.com/wp-content/uploads/2025/08/Omarchy-la-distro-del-creador-de-Ruby-on-Rails-2-scaled.png.webp)

The same pattern occurred about ten years ago in code editors. We moved from native editors such as **BBEdit**, **TextMate** (also promoted by DHH), **Notepad++**, and **Sublime** to Electron‑powered apps like **Atom**, **VS Code**, and all their forks. The hardcore migrated to **Vim** or **Emacs**, trading immediate feedback and higher usability for the steepest learning curve I’ve ever seen.

---

## Windows

The lesson is clear: native applications are losing. Windows is doing the “GUI library standard” joke—when one API fails, they make up another, only for it to fail amid the sea of alternatives that exist.

* **MFC (1992)** wrapped Win32 in C++. If Win32 was inelegant, MFC was Win32 wearing a tuxedo made of other tuxedos.  
* Then came **OLE**, **COM**, **ActiveX**. None of these were really GUI frameworks—they were component architectures—but they infected every corner of Windows development and introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.

> — *Jeffrey Snover*, in “[Microsoft hasn’t had a coherent GUI strategy since Petzold](https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/)”

Since then, Microsoft has gone through **WinForms**, **WPF**, **Silverlight**, **WinUI**, **MAUI** without success. Many enterprise and personal desktop applications still rely on Electron apps, and the last memory of coherent visual integration of the whole OS I have is of Windows 98 or 2000.

> — *Domenic Denicola*, in “[Windows Native App Development Is a Mess](https://domenic.me/windows-native-dev/)”

It turns out that recreating an OS’s UI APIs every few years is a lot of work. Coupled with intermittent attempts at sandboxing and deprecating “too powerful” functionality, each new layer has gaps where you can’t do things that were possible in the previous framework.

---

## Linux

The UI inconsistency in Linux was created by design. Different teams wanted different outcomes and had the freedom to implement them. **GTK** and **Qt** became the two reigning frameworks. While Qt is the more famous, both aim to support cross‑platform native development (once upon a time I successfully compiled *gedit* on Windows, learning a lot about C compilation, makefiles, and environment variables in the process) but are primarily used on Linux.

Luckily, applications built with different toolkits can look “okay‑ish” next to each other—something the disparate frameworks on Windows fail to achieve. How many engineer‑hours does it take to redo the Windows Control Panel?

Given the difficulty of testing the million different combinations of distros, desktop environments, and hardware, most companies do not bother with a native Linux application. They either:

1. Use Electron (minting the lock‑down), or  
2. Let the open‑source community solve it themselves (when they provide open APIs).

---

## macOS

Apple used to be a one‑book religion. Apple’s [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) were cited by every UI course worldwide. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface.

Fast forward a few decades, and Apple is doing its best worst to break all the guidelines and consistency it was once known for.

![macOS UI criticism](https://pbs.twimg.com/media/HGXc3k1b0AAZPcy?format=jpg&name=small)

Now, Apple has been:

* **Ignoring Fitts’ law** – see the discussion on [Hacker News](https://news.ycombinator.com/item?id=45288997)  
* **Making resizing windows near‑impossible** – see the series on [Noheger’s blog](https://noheger.at/blog/2026/01/11/the-struggle-of-resizing-windows-on-macos-tahoe/) (and the follow‑up attempts)  
* **Adding icons to every single menu** – see [Tonsky’s post](https://tonsky.me/blog/tahoe-icons/)

macOS is no longer the safe haven where designers can work peacefully.

---

## Electron

Everyone knows that the user experience of Electron apps sucks. The most popular complaint is memory consumption, which has been decreasing over the last decade. My main gripe (as someone who usually drives a 64 GB RAM MacBook Pro) is the lack of visual consistency and keyboard‑driven workflows.

Looking at my Dock, I have:

* **8 native apps** (e.g., TextMate and macOS system utilities)  
* **6 Electron apps** (Slack, Discord, Mattermost, VS Code, Cursor, Plexampp)

…and that’s from someone who really wishes they could avoid any Electron app at all.

Take **Cursor** (the same applies to VS Code). If you are in the agent panel, requesting your next feature, can you move to the agent list on the side panel with just the keyboard? Can you archive it? These actions should be the same across every macOS application, and even when shortcuts exist, they are not announced in the menus. Over the last decade, developers have been forgetting to add menus for actions that are already available in their HTML‑based sandboxed UI. For the record, Slack does this better than the others, but it’s not perfect.

---

## Restarting from Scratch

Together with Dart, Google wanted to design a new operating system—without the legacy of Android—for new devices. It aimed for a fresh UI toolkit ([Flutter UI](https://docs.flutter.dev/ui)), but Google gave up on the project before a real product launched. It’s one of those situations where…

*…* (the original text cuts off here)

---

*All quotes and links are retained from the original content.*

e having a monopoly (or a large enough slice of the market) is required to succeed.

Meanwhile, [Zed](https://zed.dev) did the same thing in Rust: they designed their own GPU‑renderer library ([GPUI](https://crates.io/crates/gpui)) which is cross‑platform. Despite the high speed, it lacks integration with the host OS, requiring developers to add the right bindings. Personally, I would rather have a slower renderer that integrates with my OS than the extra speed.

#### TUIs

TUIs are fast, easy to automate ([RIP Automator](https://arstechnica.com/civis/threads/apple-terminated-product-manager-of-automation-position-and-fired-sal-soghoian.1359425/)) and work reasonably well on different operating systems. You can even run them remotely without any headache‑inducing [X forwarding](https://www.tomshardware.com/how-to/forward-x-session-ssh). When native UI toolkits fail, we go back to basics. Claude and Codex have been very successful on the command line: you focus on the interaction and forget about the operating system around you. You can even drive code and apps on cloud machines, or remote into your GPU‑powered machine from your iPad. TUIs are filling the void left by Apple and Microsoft in the post‑apocalyptic world where every application looks different. This is good if you are doing art (including computer games), but not if your goal is to get out of the way and let the user do their job.

#### What’s next

A checkbox is also part of an interface. You use it to interact with a system by inputting data. Interfaces are better the less thinking they require: whether the interface is a steering wheel or an online form, if you have to spend any amount of time figuring out how to use it, that’s bad. As you interact with many things, you want homogeneous interfaces that give you consistent experiences. If you learn that **Command + C** is the keyboard shortcut for copy, you want that to work everywhere. You don’t want to have to remember to use **Ctrl + Shift + C** in certain circumstances or right‑click → Copy in others—that would be annoying.

— [John Loeber](https://substack.com/%40loeber) in *[Bring Back Idiomatic Design](https://essays.johnloeber.com/p/4-bring-back-idiomatic-design)*

We need to go back to the basics. Every developer should learn the theory of what makes a good user interface (software or not!), such as the works of **Nielsen** ([*Usability Engineering*](https://www.nngroup.com/books/usability-engineering/)), **Norman** ([*The Design of Everyday Things*](https://www.amazon.com/dp/0465050654/)) or **Johnson** ([*Designing with the Mind in Mind*](https://www.amazon.com/Designing-Mind-Understanding-Interface-Guidelines/dp/0128182024)). UI design should not be treated as a soft skill that doesn’t matter in the software‑engineering curriculum. In any course, if the UI does not make sense, the project should fail. In HCI courses, we should aim for perfect UIs. It takes work, but that work is mostly about understanding what we need; the programming is already being automated.

Operating‑system and toolkit authors should drive this investment. They should focus on making accessible toolkits that developers want to use, lowering the barrier to entry, and making those platforms last as long as possible. I do not necessarily argue for cross‑platform support, but having a single, well‑designed solution would help reduce the electron and TUI dependency.