TUIが再び戻ってきた理由
(wiki.alcidesfonseca.com)- TUI は、即時のフィードバック、自動化のしやすさ、OS をまたいで動作できることから再び注目されており、Claude や Codex のようなツールもコマンドラインで大きな成功を収めている
- Windows、Linux、macOS の ネイティブ GUI は、それぞれ不安定な API 戦略、ツールキットと環境の分散、過去のガイドラインとの一貫性低下によって、開発者とユーザーの双方に負担を増やしている
- Electron アプリは、メモリ使用量よりも視覚的一貫性の不足やキーボード中心の作業フローの弱さのほうが大きな問題であり、メニューやショートカットの統合も弱くなっている
- Google の Flutter UI の試みや、Zed の GPUI のように新しい UI スタックを作ろうとする動きもあったが、OS との統合が不十分であれば高速なレンダラーだけでは十分ではない
- 優れたインターフェースの中核は、ユーザーが考える量を減らす 一貫性 にあり、開発者と OS・ツールキットの制作者は UI 理論と使いやすいツールキットにもっと投資すべきである
TUI が再び注目される背景
- DHH の Omarchy は、TUI、Web アプリ、gnome スタイルのネイティブアプリが混在した構成になっており、TUI は即時のフィードバックと「geek points」のために使われている
- およそ 10 年前、コードエディタでも似た流れがあった
- BBEdit、Textmate、Notepad++、Sublime のようなネイティブエディタから、Atom、VSCode、その派生アプリのような Electron ベースのアプリへと移行した
- 強い好みを持つユーザーは vim や emacs に移り、即時のフィードバックと高い操作性を得る代わりに、非常に急な学習曲線を受け入れる必要があった
ネイティブ GUI が弱くなった理由
-
Windows
- Windows は一貫した GUI ライブラリ戦略を作れず、1 つの API が成功しなければ別の API を作る流れを繰り返してきた
- Jeffrey Snover は Microsoft hasn’t had a coherent GUI strategy since Petzold で、MFC、OLE、COM、ActiveX が Windows 開発全体に複雑さを広げたと述べている
- Microsoft はその後、WinForms、WPF、Silverlight、WinUI、MAUI を経たが成功できず、多くのエンタープライズ向け・個人向けデスクトップアプリは依然として Electron アプリに依存している
- Windows 全体が視覚的に一貫して統合されていた最後の時期は、Windows 98 か Windows 2000 に近い
- Domenic Denicola は Windows Native App Development Is a Mess で、数年ごとに OS と UI API を作り直すコストは大きく、サンドボックス化や機能廃止の試みが重なることで、新しい各レイヤーには以前のフレームワークで可能だったことができなくなる穴が生じると見ている
-
Linux
- Linux の UI の不一致は、設計上そうなった結果に近く、それぞれ異なるチームが異なる目標を追求する自由を持っていた
- GTK と Qt が主要フレームワークとなり、どちらもクロスプラットフォームのネイティブ開発を志向していたが、広く使われている領域は主に Linux である
- 異なるツールキットで作られた Linux アプリは並べてもある程度うまく見えることがあるが、Windows の複数のフレームワークはそのレベルの調和を実現できていない
- ディストリビューション、デスクトップ環境、ハードウェアの組み合わせが多すぎてテストが難しいため、多くの企業はネイティブ Linux アプリを作らない
- 企業は通常 Electron で Linux をサポートするか、公開 API がある場合はオープンソースコミュニティが自力で解決するようにしている
-
macOS
- Apple の Human Interface Guidelines は、世界中のユーザーインターフェースの授業で引用されるほど強い基準だった
- Xerox PARC と Apple は、優れたヒューマンインターフェースとは何かを研究した代表的な機関として挙げられる
- 最近の Apple は、過去のガイドラインとの一貫性を壊す方向に進んでいる
- macOS は Fitts の法則を無視 し、ウィンドウサイズの変更をほぼ不可能にし、修正を試みた後も問題が続き、すべてのメニューにアイコンを追加 する方向へ進んでいる
- macOS はもはや、デザイナーが安心して仕事のできる安全地帯とは言いがたくなっている
Electron アプリの限界
- 最もよく挙げられる問題は メモリ使用量 だが、この 10 年でメモリ使用量は減少する傾向にあった
- より大きな問題は、視覚的一貫性の不足 とキーボード中心の作業フローの弱さである
- 64GB RAM の MacBook Pro を使う環境でも、Dock にはネイティブアプリ 8 個と Electron アプリ 6 個が並んでいる
- ネイティブアプリ: TextMate と macOS のシステムユーティリティ
- Electron アプリ: Slack、Discord、Mattermost、VSCode、Cursor、Plexamp
- Cursor や VSCode のようなアプリでは、エージェントパネルで機能を要求した後、キーボードだけでサイドパネルのエージェント一覧へ移動したり、アーカイブしたりする操作が自然ではない
- こうした動作はすべての macOS アプリで同じ方法でできるべきだが、ショートカットがあってもメニューに表示されないことがある
- この 10 年で開発者は、アプリで可能な操作をメニューにも追加することを忘れる傾向が強まり、これはアプリケーションがサンドボックス内の HTML として実装される構造と結びついている
- Slack はほかの Electron アプリよりこの点をうまく処理しているが、完璧ではない
新しい UI スタックを作り直す試み
- Google は Dart とともに、Android の遺産を持たない新しい OS と新しいデバイス向けの UI ツールキットを作ろうとしていた
- Google は Flutter UI という新しい UI ツールキットを望んでいたが、実際の製品が出る前にプロジェクトを断念した
- このような試みは、独占的な地位か十分に大きい市場シェアがなければ成功しにくい
- Zed は Rust で似た方向を選び、独自の GPU レンダラーライブラリである GPUI を作った。このライブラリはクロスプラットフォームを志向している
- GPUI は高速だが、ホスト OS との統合がそれ自体では十分でないため、開発者が必要なバインディングを自分で追加しなければならない
- 高速なレンダラーよりも、OS と適切に統合される遅いレンダラーのほうが望ましい
TUI が埋める隙間
- Apple Automator の衰退を思わせる文脈の中で、TUI は自動化可能なインターフェースとして再び重要になっている
- TUI はリモート実行も比較的容易で、頭痛の種になりがちな X forwarding に依存する必要もない
- ネイティブ UI ツールキットが失敗すると、基本に立ち返ることになり、その結果として TUI が選択肢として浮上する
- Claude と Codex はコマンドラインで大きな成功を収めており、ユーザーは周囲の OS を気にするよりも、対話そのものに集中できる
- TUI を通じてクラウドマシン上のコードやアプリを扱ったり、iPad から GPU 搭載マシンへリモート接続したりすることもできる
- TUI は、すべてのアプリケーションがそれぞれ異なって見える環境の中で、Apple と Microsoft が残した隙間を埋めている
- 外見の違いはアートやコンピューターゲームには向いているかもしれないが、ユーザーが自分の仕事をするためにインターフェースが一歩引くべき用途には適していない
今後必要な方向
- John Loeber は Bring Back Idiomatic Design で、チェックボックスもシステムとやり取りするためのインターフェースであり、良いインターフェースとはユーザーが考える量を減らすものだと述べている
- ユーザーは多くのものとやり取りするため、一貫した体験を与える均質なインターフェースが必要である
- Command+C がコピーのショートカットなら、どこでも動作すべきであり、特定の状況で Ctrl+Shift+C や右クリック → コピーを別途覚えなければならない方式は不便である
- すべての開発者はソフトウェアだけでなく、一般的に優れたユーザーインターフェースを作る理論を学ぶべきである
- ユーザーデザインをソフトウェア工学の教育課程で重要でないソフトスキルのように扱う姿勢はやめるべきである
- どのような課程であれ UI が理解されていなければ、そのプロジェクトは失敗と見なされるべきであり、HCI の課程では完璧な UI を目標にすべきである
- 良い UI を作る作業では、必要を理解することに大半の努力が費やされ、プログラミング自体はすでに自動化されつつある
- OS とツールキットの制作者は、開発者が使いたいと思える使いやすいツールキットを作り、参入障壁を下げるための投資を主導すべきである
- 必ずしもクロスプラットフォーム対応を主張するわけではないが、そのような解決策が 1 つでもあれば、Electron や TUI への依存を減らす助けになるかもしれない
2件のコメント
私もそうですが、開発界隈は流行に過剰に敏感だと思います。TUI は、きちんとした GUI を作る能力や意思のない会社が主導しているにすぎず、実際にどれだけ多くの人が TUI を使っているのかは分かりません。
Lobste.rs の意見
むしろみんなネイティブアプリを作ってほしい。TUI はコマンドラインインターフェースと本物の GUI の欠点を合わせたようなものに見える
どの TUI プログラムもスクロールを自前で再実装しなければならないので、端末がピクセル単位のスクロールに対応していても、TUI プログラムは行単位のスクロールしかできず、動作もまちまちだ。senpai のスクロールバックは自分が使っている他のプログラムとやり方が違って、しょっちゅう見失う
インターフェースが単一のテキストパネル以上のものだという情報を端末に伝える手段もないので、テキスト選択がよく壊れる。マウスイベントを横取りすればできなくはないが、それもそれで微妙だ。TUI の IRC クライアントでは、テキスト選択をするために左右のごちゃごちゃしたパネルを隠すショートカットを押さなければならず、かなり間抜けな手順だった
グリッドに合わせなければならないという制約は、レイアウトやデザインの可能性を大きく制限する。クリック可能なボタンのように見せるスタイリングや、コンテキストメニューのようなものが思い浮かぶ。以前にこの問題について不満を書いたこともある
TUI が増えているのは、従来型 GUI フレームワークの状態がよくないことによる残念な結果だと思う。TUI フレームワークは比較的安定していて、かなり古いものを使ってもそれほど気にならない。ncurses のプログラムは今でもよく使うが、Motif のプログラムを使う姿はあまり想像できない
一方で GUI フレームワークは選択肢が少なく、保守の手間もはるかに大きい。デスクトップ環境は変わり、GUI への期待も高くなる。TUI のアクセシビリティは本当にひどいと思うが、そこまでは断言できない。変化も激しくて、GTK2 で作ったら廃止予定、GTK3 に上げたら GTK4 に行けと言われる、ということが繰り返される
シニカルに言えば、Omarchy のようなものには別の要因もある。普通の GUI である xfce4-taskmanager は退屈だが、TUI の btop はものすごくハッカーっぽく見える。人々はターミナルの美学を好み（/r/unixporn 参照）、雰囲気のために使い勝手を犠牲にする気すらあるように見える。btop がプロセス一覧を実際にフェードアウトさせている様子を見ればそう思う
今では参入障壁がもっと低くなっていることを期待していた。大半の開発者が高級言語で育っている状況では説得力が弱く見えるし、C++ の複雑さに自分が尻込みしている面もある気がする
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix クライアントのNhekoは、一度に 1 行を超えて選択することすらできない
一方 IRC クライアントは、デフォルトでこういう形を提供する
20:41 <username1> message1
20:42 <username2> message2
ときには理にかなうが、理想的には小さく短時間使うアプリやテキスト編集のような例外に限って使うのがよいと思う
たとえば lf, tig, kakoune はシェルスクリプトと相性がよく、同じスクリプトを再利用して 3 つのアプリすべてで機能を拡張できる。どれも alacritty で動いているので、3 つのアプリとシェル全体で動作するハイパーリンクも作れる
夢を見ていいなら、Emacs や acme 風の統合を許すモノクロのミニマル GUI ツールキットがあればと思う
TUI がどうして「自動化しやすい」のかよくわからない。コンソールに表示される GUI のようなものではないのか？
この記事は、TUI が「戻ってきた」主な理由を見落としている。その主張自体も疑わしいが、Claude のようなコーディングエージェントが大量にバイブコーディングされる中で、最近人気が上がったのは確かに見える
開発者は簡単な選択肢を好む。クロスプラットフォーム TUIを作るほうが GUI を作るより簡単だからだ
Web アプリが人気を得た理由も同じだ。ブラウザの道具でクロスプラットフォームアプリを作りやすかったからで、Electron が広まったのもクロスブラウザ対応の負担を取り除いた同じ文脈にある。レスポンシブ UI を作ること、UI をクロスプラットフォームにレンダリングすること、ユーザー入力をとくにアクセシビリティまで考えて処理することは、どれも難しい。だから開発者は、それを簡単にしてくれるものにすぐ飛びつく
最近は TUI 作成をさらに容易にした変化もあった。高度な機能のクロスプラットフォーム対応が改善され、複雑な詳細を抽象化した有名ライブラリが登場し、そうしたものが最近の TUI ルネサンスにつながったようだ
そのほか、記事の論点にはやや疑わしい部分もある。たとえば著者は Electron アプリの弱点として一貫性を挙げるが、人気のある TUI にも慣習を除けば一貫性はほとんどない。コーディングエージェントは似たショートカットを採用しているが、ほとんどが同じ元ネタである Claude を真似たからだ。そのショートカットはコーディングエージェントの外にはあまり広がっておらず、自分が使っている大半の TUI はショートカットも視覚言語もかなり違う
「UI をクロスプラットフォーム方式でレンダリングするのが難しい」というのも疑問だ。互換レイヤーが必要で、プラットフォームの数だけ実装が要るのはそうだが、単一プラットフォーム対応よりそこまで大幅に難しいようには見えない。もちろん対象プラットフォームのレンダリング方式があまりに違って共通 API の設計が難しいなら別だが、画面にピクセルを置くレベルではそうではないはずだ。スケーリングのような要素は処理する必要があるが、それ以上はかなり素直なはずで、そうでなければ SDL もある
たぶん、すべてのプラットフォームで UI を「ネイティブらしく見せる」話をしていたのだと思う。それは各プラットフォームで好まれるネイティブ GUI ツールキットを使う必要があるかもしれず、それらは互いに大きく異なるうえ、低レベルのレンダリング API よりずっと巨大で不安定かもしれない。そんなことに付き合うには人生は短すぎる。カラーテーマやグラフィックスタイルの一部を変える余地は残すにしても、アプリ側の設定にとどめるだろう。各 OS のグラフィック設定を読み取るのに時間を無駄にしたくない
「ユーザー入力、とくにアクセシビリティ対応が難しい」というのも妙だ。キーボードやマウスのイベントを受け取るのは些細なことだ。アクセシビリティの面では、適切なキーボードナビゲーションが必要で、全体的な使いやすさのためにも重要だし、標準およびカスタムのショートカット対応も必要だろうが、全体としては他の部分よりずっと簡単に見える
スクリーンリーダー対応は、関係するプラットフォームの API やプラットフォーム間の違いによって難しいかもしれないが、それは入力の問題というよりレンダリングの問題に近い
TUI は「復活」というより、ネイティブ GUI プログラミングの知識を失って、手元にある道具で何とかしている状態に近い。一貫した開発と投資が不足した結果だ
Qt のようないくつかの明るい例外を除けば、UI 文明は崩壊し、私たちは終末後を生きているようなものだ
Preventing the Collapse of Civilization の講演と韻を踏んでいるように感じられ、いまや AI が多くのコードを書く状況なので、この知識の崩壊がさらに広がるのではないかと心配になる
コンピュータサイエンス版のAfter Virtueが必要な気がするし、あるいは Blow のオンライン上での存在感がその役割を果たしているのかもしれない。いずれにせよ、一貫性があり、ユーザーを尊重し、学習と手間に報いてくれたコンピュータインターフェースの時代が恋しい
この記事には実質的な中身があまりなく、著者が他のすべてをひどいと思っていることを述べているだけのように見える
ひとつ言うなら、Emacs はテキスト、キーボード、ボタン、リッチメディアのインターフェースのための優れたプラットフォームだ
Go、Rust、そして今では Zig で、ncurses ではないTUI ライブラリを使い始めた人が増えたからという可能性が高い。それでも ncurses が必要だったひどい移植性問題は解決してくれた
その後、人々は新しいターミナルを作り始め、そちらの技術も押し進めるようになった。部分的には、C の代わりに Go、Rust、Zig で作れるようになったからでもある
C や C++ より楽しく、いら立ちの少ない良い選択肢を与えれば、当然人々はより新しく有用なコードを書き始める
TUI が戻ってきた本当の理由は、2026 年に署名と公証が必要な GUIを配布するには Apple に金を払い、Windows 向けには認証局にも金を払わなければならないからだ
細かい訂正だが、Zed の GPU アクセラレーション UI ライブラリはクロスプラットフォーム API の wgpu ではなく gpui だ
記事が論旨を十分に証明できているかはわからないが、MS-DOS 時代を経験し、ずっと TUI が好きだった者として口を挟んでみる。afl-fuzz を使ったことがあれば、おそらくわかるはずだ
理屈の上では、Linux において TUI はもっと大きく成功していてもよかった。テキストベースの美学を好む技術ユーザー層がいて、無骨で一貫性のない GUI 環境という「利点」もあった。ビデオカードを X サーバーでまともに動かすこと自体が問題だった時代もある
同時に、何十年ものあいだ *nix ソフトウェア開発者は、古くて珍しい端末種別までサポートすべきだという義務感を抱いていた。アプリケーションが DECwriter で正しく描画されないと一大事であるかのようで、そうした制約のもとでは良い TUI を作るのは難しかった
MS-DOS 時代には Microsoft、Borland、Norton のような企業が、機能的で反応のよいテキストベースインターフェースを完成させていた。Linux では長いあいだ、TUI 設計の「頂点」は menuconfig という怪物であり、目を細めれば vim も TUI と呼べるかもしれない、という程度だった。人々が実際にテキストモードコンソールを使っていた時代に、自分が覚えている良い Linux TUI は、Norton Commander に触発されたファイルマネージャー Midnight Commander くらいだった