别再折腾 TUI 了，原生界面才是未来
Stop Making TUIs
我最近沉迷于构建原生图形界面，从 Markdown 查看器 MDV.app 到 SageMath 计算器，再到嵌入 LLM 代理的 DJ Roomba 音乐播放器。这些应用大多由 AI 辅助生成，我几乎没写多少代码，却实现了过去需要大量手工编码才能完成的功能。文章指出，TUI 和 CLI 是受限于早期硬件的产物，如今在 AI 和现代框架（如 SwiftUI）支持下，构建高效、美观的原生 GUI 已变得异常简单。我们不应再固守终端界面，而应拥抱图形界面的无限可能。
我们构建终端界面是因为不得不这样做，而不是因为应该这样做。
HN 评论区
134- joshka
作为 ratatui 库的维护者，不——请别停止开发 TUI；)
作为库外的开发者，我很欣赏文中提到的那些“手痒想写点东西”的小应用。我目前正在开发一个用 SwiftUI 写的国际象棋棋谱构建器，它也属于这类应用。如果不是因为有代码代理（coding agents），我可能根本不会去探索这个想法。
我同意文章的观点，终端的形状很怪异，你不得不去对抗历史遗留的规范等等。不过我的关键观察是，终端应用和库之间的不匹配，其根本原因都在于它们围绕字符单元（character cells）和光标移动构建，再加上各种 CSI/OSC/ASC/DEC/xterm/... 协议。这些协议复杂、支持度参差不齐，且交互方式怪异。
要想获得良好的终端用户体验，我认为答案可能是抛弃所有这些兼容性烂摊子，重新设计一种现代终端协议，将无障碍访问、区域划分、滚动、选择、完善的键盘支持等特性直接内置其中。
我知道 Mitchell Hashimoto 对此有略微不同的看法，他的观点似乎是定义更多协议内容并在此基础上继续构建。我觉得这大概能解决 95% 的问题。但要做到 100% 的完美，则需要彻底的替换。
- cush
制表符（Tabs）与空格（Spaces）之争。
我一直很欣赏 TUI 的优点，而对 GUI 的优点则欣赏较少。我小时候完全没接触过电脑，在我成年后的第一份工作中，我不得不在 Papa John's 使用 TUI 来录入订单。它比我后来在其他餐厅使用的任何 GUI 驱动的系统都要快 20 倍（键盘速度对我而言是制胜法宝，完美契合我的思维方式）。我想我花了 5 分钟就学会了。那时我只是个普通打工仔，只想付账单。
不知道为什么非要贬低别人的偏好，这篇文章在这方面真的很糟糕。
- bayindirh
也许在 macOS 上，你拥有制作高质量 GUI 的优秀 API、库和工具包，但如果你想编写开源软件或面向开源平台，你的选择就非常有限且质量堪忧。
在 Linux/BSD 阵营，大多数工具包质量都不高，你会继承各种微妙的 bug 和怪异的行為。绝大多数质量“卓越”的软件并不使用这些工具包，而是直接与合成器（compositor）交互。在这种情况下，开发 GUI 的投入比 TUI 高出几个数量级，而 TUI 通常已经“足够好”了。
我确实很希望在很多场景下能用上 GUI。但当 TUI 只需几周就能完成时，等价的 GUI 可能需要几个月。
- tescreal
TUI 相对于 GUI 最大的优势之一在于，我可以运行任意数量的 TUI 实例。
而 GUI 的开发者必须决定是否允许我打开多个窗口。“标签页界面就足够了！”——太好了，这意味着我永远无法同时查看两个屏幕的信息。
- matheusmoreira
一个不知何故不在浏览器里的 Wiki，一个没有明显键盘快捷键的电视遥控器替代品，一个看起来像 Jupyter 却无法编辑的东西（据我所知），以及两个带有技能（skills）的聊天界面。随你便吧，但这不是我使用电脑的方式。
- JodieBenitez
别总告诉别人该怎么做 :/
让人们享受他们喜欢的东西吧。
- sjbzbeiks
TUI 的好处在于：它们与平台无关。而使用 SwiftUI 开发的应用则被绑定在 macOS 上。
- never_inline
同意这里的其他评论：继续开发 TUI 吧。完全由键盘驱动、紧凑的界面，生活在我的终端里，和我的其他 CLI 开发工具在一起，这才是最棒的！