Why TUIs are back

为什么 TUI（终端用户界面）正在回归

Terminal User Interfaces (TUIs) are making a comeback. DHH’s Omarchy 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 and the unavoidable gnome-style native applications that really do not fit well in the style of the distro. 终端用户界面（TUI）正在回归。DHH 的 Omarchy 由三种类型的用户界面组成：用于即时反馈和极客加分的 TUI；因为 37signals（他的公司）销售 SaaS 网络应用而存在的 Web 应用；以及那些确实与发行版风格不太协调、却又不可避免的 GNOME 风格原生应用。

The same pattern occurred around 10 years ago in code editors. We came from the native editors of BBEdit, Textmate (also promoted by DHH), Notedpad++ and Sublime to Electro-powered apps like Atom, VSCode and all its forks. The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen. 大约 10 年前，代码编辑器领域也出现了同样的模式。我们从 BBEdit、Textmate（也曾被 DHH 推崇）、Notepad++ 和 Sublime 等原生编辑器，转向了 Atom、VSCode 及其所有分支等基于 Electron 的应用。硬核玩家则转向了 Vim 或 Emacs，他们用即时反馈和更高的可用性，换取了我所见过的最陡峭的学习曲线。

Windows

The lesson is clear: Native applications are loosing. Windows is doing the GUI library standard joke. Because one API does not have success, they make up another one, just for that one to fail within 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 教训很明确：原生应用正在败退。Windows 在 GUI 库标准上上演着一场笑话。因为一个 API 不成功，他们就再编造一个，结果这个新 API 又在现有的众多替代方案中失败了。MFC（1992 年）用 C++ 封装了 Win32。如果说 Win32 不够优雅，那么 MFC 就是穿着由其他燕尾服缝制而成的燕尾服的 Win32。接着是 OLE、COM、ActiveX。这些都不是真正的 GUI 框架——它们是组件架构——但它们渗透到了 Windows 开发的每一个角落，引入了一种认知复杂度，让克尔凯郭尔（Kierkegaard）的著作读起来都像海明威（Hemingway）一样简单。—— Jeffrey Snover，《自 Petzold 以来，微软再无连贯的 GUI 策略》

Since then, Microsoft has gone through Winforms, WPF, Silverlight, WinUIs, MAUI without success. Many enterprise and personal desktop application 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. It turns out that it’s a lot of work to recreate one’s OS and UI APIs every few years. Coupled with the intermittent attempts at sandboxing and deprecating “too powerful” functionality, the result is that each new layer has gaps, where you can’t do certain things which were possible in the previous framework. — Domenic Denicola, in Windows Native App Development Is a Mess 自那以后，微软经历了 Winforms、WPF、Silverlight、WinUI、MAUI，却均未成功。许多企业和个人桌面应用仍然依赖 Electron 应用，而我对整个操作系统视觉整合连贯性的最后记忆还停留在 Windows 98 或 2000。事实证明，每隔几年就重构一次操作系统和 UI API 是项巨大的工程。再加上断断续续的沙盒化尝试和对“功能过强”特性的弃用，结果就是每一层新架构都有漏洞，导致你在旧框架中能做的事情，在新框架中反而做不到了。—— Domenic Denicola，《Windows 原生应用开发是一团糟》

Linux

The UI inconsistency in Linux was created by design. Different teams wanted different outcomes and they had the freedom to do it. GTK and Qt became the two reigning frameworks. While Qt is most known for it, both aimed to support cross-platform native development (once upon a time, I successfully compiled gedit on Windows, learning a lot about C compilation, make files and environment variables in the process) but are only widely used in Linux land. Luckily, applications made in the different toolkits can look okay-ish next to each other, something that the different frameworks on Windows fail to achieve. How many engineer-hours does it take to redo the windows Control Panel? Given the difficulty in testing the million different combinations of distros, desktop environments and hardware in general, most companies do not bother with a native Linux application — they either address it using electron (minting the lock-down), or they let the open-source community solve it self (when they have open APIs). Linux 的 UI 不一致性是刻意为之的。不同的团队想要不同的结果，并且他们有自由去实现。GTK 和 Qt 成为了两大主流框架。虽然 Qt 在这方面更出名，但两者都旨在支持跨平台原生开发（曾几何时，我成功在 Windows 上编译了 gedit，并在此过程中学到了很多关于 C 语言编译、Makefile 和环境变量的知识），但它们目前主要还是在 Linux 领域被广泛使用。幸运的是，使用不同工具包制作的应用程序放在一起看起来还算协调，这是 Windows 上不同的框架所无法实现的。重做 Windows 控制面板需要多少工程师工时？考虑到测试数百万种发行版、桌面环境和硬件组合的难度，大多数公司根本懒得开发 Linux 原生应用——他们要么使用 Electron 来解决（从而锁定环境），要么就让开源社区自行解决（如果他们有开放 API 的话）。

macOS

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox Park 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 the best worst it can to break all the guidelines and consistency it was known for. Now, Apple has been ignoring Fitts’ law, making resizing windows near-impossible (even after trying to fix it) and adding icons to every single menu. MacOS is no longer the safe heaven where designers can work peacefully. 苹果曾经是“一书教派”（指其人机交互指南）。苹果的《人机交互指南》（Human Interface Guidelines）曾被全球每一门用户界面课程引用。施乐帕洛阿尔托研究中心（Xerox Park）和苹果是研究什么是良好人机界面的两家机构。几十年过去了，苹果正在竭尽全力破坏它曾经引以为傲的所有准则和一致性。现在，苹果无视费茨定律（Fitts’ law），让调整窗口大小变得几乎不可能（即使在尝试修复之后），并给每一个菜单都加上了图标。macOS 不再是设计师可以安静工作的避风港了。

Electron

Everyone knows that the user experience of electron apps sucks. The most popular claim is the memory consumption, which to be fair has been decreasing over the last decade, but my main complaint (as I usually drive a 64GB RAM MacBook Pro) is the lack of visual consistency and lack of keyboard-driven workflows. Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all. 大家都知道 Electron 应用的用户体验很糟糕。最常见的抱怨是内存占用，平心而论，过去十年里这一问题有所改善。但我主要的抱怨（作为一个通常使用 64GB 内存 MacBook Pro 的用户）在于视觉一致性的缺失和键盘驱动工作流的匮乏。看看我的 Dock 栏，我有 8 个原生应用（TextMate 和 macOS 系统工具）和 6 个 Electron 应用（Slack、Discord、Mattermost、VSCode、Cursor、Plexamp）。而这还是出自一个真心希望完全不用 Electron 应用的人之口。

Let us take the example of Cursor (but would be true for VSCode as well). 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 are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus. And over the last decade, developers have been forgetting to add menus to do the same things that are available in their application (mostly because the application is HTML within its sandbox). For the record, Slack does this better than the others, but it’s not perfect. 以 Cursor 为例（VSCode 也一样）。如果你在 Agent 面板中请求下一个功能，你能仅通过键盘移动到侧边栏的 Agent 列表吗？你能归档它吗？这些操作在每个 macOS 应用中都应该是统一的，即使有快捷键，它们也不会在菜单中显示。在过去十年里，开发者们逐渐忘记了在菜单中添加与应用内功能对应的选项（主要是因为应用本质上是沙盒里的 HTML）。顺便提一下，Slack 在这方面做得比其他应用好，但也不完美。

Restarting from scratch

从零开始

Together with Dart, Google wanted to design a new operating system, without all the legacy of Android, for new devices. It wanted a fresh UI toolkit (Flutter UI) but Google gave up on the project before a real product was launched. It’s one of those situations where having a monopoly (or a large enough slice of the market) is required to succeed. Meanwhile, Zed did the same thing in Rust: they designed their own GPU-renderer library (wgpu) which is cross-platform. Despite the high-speed, it lacks integration with the host OS on itself, requiring the developers to add the right bindings. Personally, I would rather have a slow renderer that integrated with my OS than the extra speed. Google 曾希望结合 Dart 设计一个新的操作系统，摆脱 Android 的所有历史包袱，用于新设备。他们想要一套全新的 UI 工具包（Flutter UI），但在产品正式发布前，Google 就放弃了这个项目。这属于那种必须拥有垄断地位（或足够大的市场份额）才能成功的案例。与此同时，Zed 用 Rust 做了同样的事情：他们设计了自己的 GPU 渲染库（wgpu），它是跨平台的。尽管速度很快，但它缺乏与宿主操作系统的原生集成，需要开发者自行添加正确的绑定。就我个人而言，我宁愿要一个与操作系统深度集成的慢速渲染器，也不要那种额外的速度。

TUIs

TUI

TUIs are fast, easy to automate (RIP Automator) and work reasonably well in different operating systems. You can even run them remotely without any headache-inducing X forwarding. When the 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 c TUI 速度快，易于自动化（安息吧，Automator），并且在不同的操作系统中都能良好运行。你甚至可以在远程运行它们，而无需处理令人头疼的 X 转发。当原生 UI 工具包失效时，我们回归了基础。Claude 和 Codex 在命令行上非常成功：你专注于交互，而忘记了周围的操作系统。你甚至可以驱动 c