終端機使用者介面（TUI）正在捲土重來。DHH 的 Omarchy 由三種類型的使用者介面組成：TUI，用於即時回饋和額外的極客分數；Web 應用程式，因為 37signals（他的公司）銷售 SAAS 網路應用程式；以及不可避免的 GNOME 風格原生應用程式，它們與發行版的風格並不十分契合。

大約十年前，程式碼編輯器也發生了類似的模式。我們從 BBE dit、Textmate（也由 DHH 推廣）、Notepad++ 和 Sublime 等原生編輯器，轉向了像 Atom、VS Code 及其所有分支的 Electron 驅動應用程式。硬核玩家則轉向了 Vim 或 Emacs，用最陡峭的學習曲線換取了即時回饋和更高的可用性。

教訓很明顯：原生應用程式正在失勢。Windows 正在上演 GUI 函式庫標準的笑話。因為一個 API 不成功，他們就制定另一個，結果這個 API 在現有的眾多替代方案中失敗了。

MFC（1992）用 C++ 包裝了 Win32。如果說 Win32 不優雅，MFC 就是 Win32 穿著由其他晚禮服製成的晚禮服。然後是 OLE、COM、ActiveX。這些都不是真正的 GUI 框架——它們是元件架構——但它們滲透到 Windows 開發的每個角落，並引入了柯爾凱 अभियांत्रिकी都顯得像海明威一樣複雜的認知複雜度。

— Jeffrey Snover，《Microsoft 自從 Petzold 以來就沒有連貫的 GUI 策略》

從那以後，Microsoft 經歷了 Winforms、WPF、Silverlight、WinUIs、MAUI，但都沒有成功。許多企業和個人桌面應用程式仍然依賴 Electron 應用程式，而我對整個作業系統的連貫視覺整合的最後記憶是 Windows 98 或 2000 年。

事實證明，每隔幾年就重寫一次作業系統和 UI API 是非常耗時的工作。再加上間歇性地嘗試沙盒化和棄用「過於強大」的功能，結果是每一層都有漏洞，你無法做在前一個框架中可能做到的事情。

— Domenic Denicola，《Windows 原生應用程式開發一團糟》

Linux 中的 UI 不一致是設計使然。不同的團隊想要不同的結果，並且他們有自由這樣做。GTK 和 Qt 成為了兩個主要的框架。雖然 Qt 以此聞名，但兩者都旨在支援跨平台原生開發（曾經，我成功地在 Windows 上編譯了 gedit，在此過程中學到了很多關於 C 編譯、Makefile 和環境變數的知識），但它們只在 Linux 領域廣泛使用。幸運的是，用不同工具包製作的應用程式放在一起看起來還算可以，這是 Windows 上不同框架無法實現的。重做 Windows 控制面板需要多少工程師小時？

鑑於測試各種發行版、桌面環境和硬體的 مليون種組合的難度，大多數公司都不 bother 製作原生 Linux 應用程式——它們要麼透過 Electron 解決（鎖定），要麼讓開源社群自行解決（當它們有開放 API 時）。

Apple 曾經是一個統一的宗教。Apple 的人機介面指南曾被世界各地的所有使用者介面課程引用。Xerox PARC 和 Apple 是研究良好人機介面意義的兩家機構。快轉幾十年，Apple 正在盡其所能打破它曾經聞名的所有指南和一致性。

現在，Apple 已經忽略了 Fitts 定律，使得調整視窗大小幾乎不可能（即使在嘗試修復之後），並在每個選單中添加了圖標。macOS 不再是設計師可以安心工作的安全天堂。

眾所周知，Electron 應用程式的使用者體驗很糟糕。最常見的說法是記憶體消耗，說實話，這在過去十年中一直在下降，但我的主要抱怨（因為我通常使用 64GB RAM 的 MacBook Pro）是視覺一致性的缺乏和鍵盤驅動工作流程的缺乏。看看我的 Dock，我有 8 個原生應用程式（Textmate 和 macOS 系統工具）和 6 個 Electron 應用程式（Slack、Discord、Mattermost、VS Code、Cursor、Plexamp）。而這是一個真正希望避免任何 Electron 應用程式的人。

以 Cursor 為例（但 VS Code 也一樣）。如果你在代理面板中請求你的下一個功能，你能只用鍵盤移動到側面板的代理列表嗎？你能封存它嗎？這些應該在每個 macOS 應用程式中都相同的操作，即使有快捷鍵，它們也沒有在選單中顯示。在過去的十年裡，開發者們一直在忘記添加選單來執行應用程式中可用的相同操作（主要是因為應用程式是沙盒內的 HTML）。順帶一提，Slack 比其他應用程式做得更好，但並不完美。

Google 曾希望與 Dart 一起設計一個新的作業系統，擺脫 Android 的所有遺留問題，用於新設備。它想要一個全新的 UI 工具包（Flutter UI），但 Google 在真正產品推出前就放棄了該專案。這是擁有壟斷地位（或足夠大的市場份額）才能成功的局面之一。

同時，Zed 在 Rust 中做了同樣的事情：他們設計了自己的 GPU 渲染器函式庫（GPUI），它是跨平台的。儘管速度很快，但它本身缺乏與主機作業系統的整合，需要開發者添加正確的綁定。個人而言，我寧願使用一個與我的作業系統整合的慢速渲染器，而不是額外的速度。

TUI 速度快，易於自動化（RIP Automator），並且在不同的作業系統上運行良好。你甚至可以在沒有令人頭痛的 X 轉發的情況下遠端運行它們。當原生 UI 工具包失敗時，我們就回歸基本。Claude 和 Codex 在命令列上取得了巨大的成功：你專注於互動，而忘記了周圍的作業系統。你甚至可以在雲端機器上驅動程式碼和應用程式，或者從你的 iPad 遠端連接到你的 GPU 驅動機器。TUI 正在填補 Apple 和 Microsoft 在後末日世界中留下的空白，在這個世界裡，每個應用程式看起來都不同。如果你在做藝術（包括電腦遊戲），這很好，但如果你的目標是讓使用者能夠順利完成工作，那就不是了。

核取方塊也是介面的一部分。你用它來透過輸入資料與系統互動。介面越不需要思考越好：無論介面是方向盤還是線上表單，如果你必須花費任何時間來弄清楚如何使用它，那就不好了。當你與許多事物互動時，你想要同質化的介面，它們能給你一致的體驗。如果你學到 Command + C 是複製的鍵盤快捷鍵，你希望它在任何地方都有效。你不想在某些情況下必須記住使用 CTRL + Shift + C，或在其他情況下右鍵單擊 → 複製，那會很煩人。

— John Loeber，《帶回慣用設計》

我們需要回歸基本。每個開發者都應該學習什麼構成良好使用者介面的理論（無論是軟體還是非軟體！），例如 Nielsen、Norman 或 Johnson，並停止將使用者設計視為軟體工程課程中不重要的軟技能。在任何課程中，如果 UI 沒有任何意義，專案就應該被當掉。而在 HCI 課程中，我們應該以完美的 UI 為目標。這需要付出努力，但這些努力主要是關於理解我們需要什麼。程式設計本身已經在自動化了。

作業系統和工具包作者應該推動這項投資。他們應該專注於創建開發者願意使用的易於存取的工具包，並降低入門門檻，使這些平台盡可能持久。我不一定主張跨平台支援，但擁有一個這樣的解決方案將有助於減少對 Electron 和 TUI 的依賴。