为什么 TUIs 再次流行

Source: Hacker News

（请提供需要翻译的正文内容，我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。）

概述

DHH 的 Omarchy 由三类用户界面组成：

• TUIs – 用于即时反馈和额外的极客积分
• Webapps – 因为 37signals（他的公司）出售 SaaS Web 应用
• Native applications – 那些不太符合发行版风格、不可避免的 GNOME‑style 应用

大约十年前，代码编辑器也出现了同样的模式。我们从 BBEdit、TextMate（同样由 DHH 推广）、Notepad++ 和 Sublime 等本地编辑器，转向基于 Electron 的应用，如 Atom、VS Code 以及它们的所有分支。硬核用户则迁移到 Vim 或 Emacs，以牺牲即时反馈和更高的可用性为代价，选择了我见过的最陡峭的学习曲线。

Windows

教训很明确：原生应用正在失势。Windows 正在玩 GUI‑库‑标准的笑话——当一个 API 失效时，他们又编造另一个，结果在层出不穷的替代方案中再次失效。

• MFC (1992) 用 C++ 包装了 Win32。如果说 Win32 不够优雅，MFC 就是穿着由其他礼服拼凑而成的礼服的 Win32。
• 接着出现了 OLE、COM、ActiveX。这些其实都不是 GUI 框架——它们是组件架构——但它们渗透到 Windows 开发的每一个角落，并引入了一种认知复杂度，让 Kierkegaard 的作品读起来像 Hemingway。

“— Jeffrey Snover, in Microsoft hasn’t had a coherent GUI strategy since Petzold”

从那以后，Microsoft 轮流推出 WinForms、WPF、Silverlight、WinUI、MAUI，却始终未能取得持久成功。许多企业和个人桌面应用仍然依赖 Electron，而我对整个操作系统统一视觉集成的最后记忆只能追溯到 Windows 98 或 2000。

“— Domenic Denicola, in Windows Native App Development Is a Mess*”

每隔几年重新创建一次操作系统的 UI API 工作量巨大。再加上间歇性的沙箱化尝试和对“过于强大”功能的废弃，每一层新框架都会留下空白，使得一些在前一框架中可能实现的功能在新框架中无法完成。

Linux

Linux 中的 UI 不一致是有意为之。不同的团队想要不同的结果，并且拥有实现它们的自由。GTK 和 Qt 成为两大主流框架。虽然 Qt 更为知名，但两者都旨在支持跨平台原生开发（曾经我成功在 Windows 上编译了 gedit，在此过程中学到了很多关于 C 编译、makefile 和环境变量的知识），但主要在 Linux 上使用。

幸运的是，使用不同工具包构建的应用程序放在一起看起来还能“凑合”——这是各自分散的 Windows 框架所做不到的。重新做一遍 Windows 控制面板需要多少工程师工时？

鉴于测试成千上万的发行版、桌面环境和硬件组合的难度，大多数公司避免原生 Linux 应用。他们要么发布 Electron 应用（制造锁定），要么让开源社区自行解决问题（当有开放的 API 时）。

macOS

Apple 曾经是一种唯一的教条。Apple 的 Human Interface Guidelines（人机界面指南）在全球所有 UI 课程中都有被引用。Xerox PARC 和 Apple 是研究优秀人机界面的两大机构。快进几十年，Apple 正在竭尽所能（最糟糕地）打破它曾经以之著称的所有指南和一致性。

现在，Apple 已经：

• 忽视 Fitts’ law（Hacker News 讨论）
• 使窗口大小调整几乎不可能（2026 年 1 月帖子，2026 年 2 月后续）
• 在每个菜单中添加图标（Tonsky 的博客）

macOS 已不再是设计师们能够安然工作的安全港。

Electron

大家都知道 Electron 应用的用户体验很糟糕。最常见的抱怨是内存消耗，尽管过去十年它已经在下降。作为一台配备 64 GB RAM 的 MacBook Pro 用户，我最在意的是视觉一致性缺失以及缺乏键盘驱动的工作流。

看看我的 Dock，我有八个原生应用（TextMate 和 macOS 系统工具）和六个 Electron 应用（Slack、Discord、Mattermost、VS Code、Cursor、Plex AMP）。而且我本来真的希望能完全避免使用任何 Electron 应用。

以 Cursor 为例（VS Code 同样适用）。如果你在代理面板中请求下一个功能，能仅用键盘切换到侧边面板的代理列表吗？能归档它吗？这些操作在每个 macOS 应用中都应该保持一致，然而即使存在快捷键，也没有在菜单中标示出来。过去十年里，开发者常常忘记为已经在基于 HTML 的沙盒 UI 中提供的操作添加菜单。需要说明的是，Slack 在这方面做得比其他的好一些，但仍然不够完美。

从头开始

与 Dart 一起，Google 想要为新设备设计一个全新的操作系统——不带 Android 的遗留问题。它的目标是全新的 UI 工具包（Flutter UI），但 Google 在真正的产品推出之前就放弃了该项目。这就是那种有前景的全新尝试却从未起步的情况。

Source:

垄断与市场份额

拥有垄断（或足够大的市场份额）是取得成功的必要条件。

与此同时，Zed 在 Rust 中做了同样的事：他们设计了自己的跨平台 GPU 渲染库（GPUI）。尽管速度很快，但它缺乏与宿主操作系统的集成，需要开发者自行添加相应的绑定。就我个人而言，我宁愿使用速度稍慢但能与我的操作系统集成的渲染器，也不愿为了额外的性能而牺牲集成度。

TUIs

TUIs（文本用户界面）快速、易于自动化（RIP Automator），并且在不同操作系统上表现相当不错。你甚至可以远程运行它们，而无需头疼的 X 转发。

当原生 UI 工具包失效时，我们回归基础。Claude 和 Codex 在命令行上取得了极大成功：你只需关注交互本身，而不必在意周围的操作系统。你甚至可以在云机器上驱动代码和应用，或从 iPad 远程连接到你的 GPU 机器。

TUIs 正在填补 Apple 与 Microsoft 在后末日世界中留下的空白——在那个每个应用看起来都不一样的时代。这对从事艺术（包括电脑游戏）的人有好处，但如果你的目标是让用户专注于自己的工作，而不是被界面所干扰，则不适用。

接下来会怎样

复选框也是界面的一部分。你通过它向系统输入数据进行交互。界面越不需要思考就越好：无论是方向盘还是在线表单，如果你必须花时间去弄清楚如何使用，那就是糟糕的设计。

当你与大量事物交互时，你希望拥有同质化的界面，以获得一致的体验。如果你已经学会 Command + C 是复制的快捷键，你就希望它在所有地方都能使用。你不想在某些情况下记得使用 Ctrl + Shift + C，或在其他情况下右键 → 复制——这会让人恼火。

— John Loeber in Bring Back Idiomatic Design

我们需要回归基础。每位开发者都应该学习什么构成优秀用户界面的理论（无论是软件还是其他），例如 Nielsen、Norman、Johnson 的著作：

• Nielsen – Usability Engineering
• Norman – The Design of Everyday Things
• Johnson – Designing with the Mind in Mind

不要把用户设计当作软技能而在软件工程课程中忽视它。任何课程中，如果 UI 不合逻辑，项目就应该失败。在 HCI（人机交互）课程中，我们应当追求完美的 UI。这需要付出努力，但大部分工作是理解需求；编程本身已经在被自动化。

操作系统和工具包的作者应当推动这项投入。他们应专注于打造开发者愿意使用的可访问工具包，降低入门门槛，并让这些平台尽可能长久。我并不一定主张跨平台支持，但拥有这样一种解决方案有助于减少对 Electron 和 TUI 的依赖。