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 への依存を減らす助けになるかもしれない
4件のコメント
私もそうですが、開発界隈は流行に過剰に敏感だと思います。TUI は、きちんとした GUI を作る能力や意思のない会社が主導しているにすぎず、実際にどれだけ多くの人が TUI を使っているのかは分かりません。
Hacker News の意見
数字だけを見るなら、TUI が人気な本当の理由は Claude Code で、残りはそれに比べれば背景雑音に近いと思う
最初に TUI を作りたくなったのは、SSH 経由でアプリを配布するという発想のためだった。SSH アプリはローカルインストールが不要という点でブラウザに似ている
https://pico.sh を面白く触っている大きな理由も、TUI 配布にユーザーの介入がまったく要らないからだ
重いブラウザベース UI から離れたいという欲求と、ターミナル描画の限界を試してみたいという好奇心が原因だと思う
新しくて面白い技術で新しいシステムを作る代わりに、GPU アクセラレーション付きタイプライターエミュレータ を作っている。ノスタルジーと技術的盲信が混ざった妙な形だ
SSH の上にはどんなプロトコルでも流せる。むしろリモートのビットマップディスプレイに描画する方向へ進んでほしい
X Window は設計が優れていたわけではないがネットワーク透過性があり、Plan 9 の devdraw はリモートのグラフィックプログラムがアセットを上げた後、線描画コマンドを RPC で送るレンダリングエンジンだった
vim で本当に難しいのは、モーダルエディタで最も核心的な コマンドモードへの復帰 のために指を Escape まで伸ばさないといけない点だけだ
理想的な流れは素早く編集して即座にコマンドモードへ戻ることなのに、Escape を使うのは歴史的遺物だと指摘しておくべきだ
だから CapsLock を Escape にグローバル再マップすればいい。Linux と macOS は GUI 設定だけで可能で、Windows もレジストリキーを作成または修正すれば 1 分で終わる
それ以外は vim-tutor で基本を学び、時間のかかる作業が出てきたときに調べればいいので、学習曲線がどこにあるのかよくわからない。問題はモーダル編集にあまりにも早く慣れてしまい、ない環境が石器時代のように感じられる点だ
最近は vim に hjkl が必要な理由は、実はキーボード配列が矢印キーに向いていないからだと思っている。タイプライターには矢印がなかったが、コンピュータでは矢印が重要だ
スペースバーがあんなに大きい必要もないし、両方の親指が使う理由もない。小さな矢印クラスタをスペースバーの左か右の一部の位置に移せば、ずっと良くなる気がする
hjkl ハックはハッカー向けエディタでしか通じないが、一般的なソフトウェアでも矢印は多用するし、今の配列は手にかなり悪い。手全体を動かさず親指で矢印を押そうとして炎症が出始めた
手を上げてホームポジションから外し、また戻すことになるので、そうでなければ静かに蓄積する RSI のポイントを減らしてくれる
同じ理由で、もう片方の手では矢印キーもよく使う。もちろん hjkl もかなり使うが
https://github.com/microsoft/PowerToys
jjにマップすれば終わりだそれに
Ctrl + [は標準的なターミナル/ASCII では Esc なので、Esc まで手を伸ばすより少し楽かもしれないOS ベンダーの私利私欲が崩れ落ちた後に残った灰が、TUI 流行のように見える
良い汎用 UI は一つもない。まだブラウザが最もましでかなり成功したが、サンドボックスのせいでローカルファイルやネットワークアクセスが必要な作業には不向きだったり摩擦が大きかったりする。単純なものを動かすにはオーバーヘッドも馬鹿げて大きい
リモートアクセスはさらにひどい。Windows ホストで動いているアプリに Mac からアクセスできるのか、トンネル接続でフォワードできるのか、といった問題が出てくる
TUI は必要なことをしてくれる単純な 汎用プロトコル であり、リモート性が前提だ。ローカルで使うものが SSH 接続の上でも自然に動く
何もかも互換性をなくしたりエコシステムに縛り付けたりする戦略が勝つと思っていた OS ベンダーたちへの大きな中指でもある
Notcurses と Ratatui は ncurses に大きく貢献した
Windows 11 はとても良い例で、ああいった大げさなものは本当に必要ない
TUI には戻ってきてほしくない。どんな日でも TUI より Web インターフェース を選ぶ
やたら賢しらなフォントをインストールする必要もないし、正しく表示させるためにターミナル設定をいじる必要もないし、作った人が最高だと思ったナビゲーションショートカットを推測する必要もない
OS 標準のテキストナビゲーションが効く本当のテキスト編集や、パスワードマネージャーやテキストエキスパンダーなどとのより良い統合もある
自分は CLI の中で暮らし、ショートカット一つでターミナルを開くが、ターミナルが唯一の選択肢だった時代以降、技術は大きく進歩しており、UI を作るためのより良い選択肢も多い
この TUI ブーム全体がただの ファッショントレンド に見える
誰もネイティブ UI 開発に投資しないからだ。Electron は、使いやすい GUI スタックがあれば企業が採用する証拠だ
大きなアプリならパッケージングや配布にかかる時間は全体の中で小さく、ファイルサイズもそれほど気にしないが、小さなアプリはそうではない
Windows 向けアプリは簡単で、小さなバイナリがフォームを開き、ダブルクリックで実行でき、インストールも不要だ
Linux で同じことをしようとすると、GTK や Qt が入っている保証がないので、スタンドアロンにするには事実上 OS 全体を一緒に送るしかない。そうするとファイルサイズが大きくなる
Python も Windows ユーザーに Python が必要だったり、インタプリタを同梱しなければならなかったりして厄介だ
まだあり得る代案は Java のように単一の
.jarファイルをどんなシステムでも実行する方式だが、Oracle がライセンスを変え、JavaFX はもう Java に同梱されていない。Swing はまだ含まれているただキーボードショートカット付きのメニューバーを表示したいだけなのに、なぜすべての OS でメニューバーにアクセスできるメニューバー VM みたいなものがないのかわからない
Electron でブラウザ丸ごと送っているのは愚かだ。ユーザーが Flash のデスクトップアプリ版みたいなプラットフォームをインストールし、すべてのアプリがそれを使う方式であるべきだ
DOS ゲームを配布するほうがデスクトップアプリより簡単かもしれない。DOS ゲームを動かしたい人は DOS エミュレータをすでに入れているだろうから
必要なのは、使いやすく、クロスプラットフォームで、オープンソースで、できれば選んだプログラミング言語から使えるフレームワークだ
もっと大きな問題は人材だ。Web 開発ができる人が多いので、その人材をデスクトップにも使いたくなり、デスクトップが JavaScript の Electron ならそれがずっと簡単になる
GUI のような機能を作り直そうとするターミナル UI はよく理解できない。コンピュータインターフェースはもっと良くなるべきではないのか
もう線や図形を描いているふりをするために文字グリッドへ制限される必要はない。Kitty や iTerm のような非標準ターミナルなしでは画像表示すらできない
優れたクロスプラットフォームのストリーミング UI システムがないのは残念だ。Web はそれなりに優れているが、この目的には明らかにもっと良い何かがあり得る。Flutter は悪くないがオンデマンド性が足りず、Dart に縛られすぎている
人々は GUI を求めているが、結局 TUI の中の GUI のようなもので回避するしかない
ポータブルで、リモート実行でき、ソケットを露出しなくてもより安全に動かせて、デスクトップ全体を起動しなくてもよい何かを求めている
ルートレスのウィンドウは事実上死に、残ったのは Web インターフェースとその諸問題か、あるいは皆がすでに持っている SSH 接続だけで済む TUI だ
昔は Tcl/Tk で適当に作って X Window でウィンドウを出せばよかったが、今では簡単ではなく、リモート X を使う人もいない
最小公倍数は SSH で、そこに合うものだけが生き残る
対応していないと挙げられている複数のターミナルも GNOME VTE ベースだが、そちらのサポートは進行中で、バグトラッカーを見るとほぼ終わっているようだ
X11 で最も標準的なターミナルに近い xterm もこれに含まれる
[0] https://www.arewesixelyet.com/
堅牢で信頼できる GUI ツールキットがあるわけでもなく、どれもそれぞれ異なるバグと注意点だらけだ
Flutter は悪くないと言われるが、Flutter でアプリをビルドする過程自体が悪夢だという点を無視しなければならない。Flutter 自体も誰でもコンパイルできるように設計されている感じではなく、実際にはディストリビューションがその問題を隠しているだけだ
そして Web ベース UI が必ずしも重い必要はない。HN がそうでないのと同じように
常にターミナルを開いていて、Bash スクリプトで生活を自動化し、VIM/TMUX を使う立場でも、ほとんどの TUI はまともな GUI より二歩遅れている
気まぐれなナビゲーションやショートカット、壊れたコピー&ペースト、環境との統合不足が代表的だ
核心的な問題は、プログラミング言語にきちんと統合されていたり標準ライブラリの一部だったりする、まともな クロスプラットフォーム GUI プラットフォーム がないことだ
Swing はネイティブブラウザ要素へのアクセスが弱く、Tk はブラウザコンポーネントやドラッグ&ドロップが弱く、wxWidgets はコミュニティが小さく、バインディングも一度ならず蘇生が必要だったように見える
Qt はいつでももっと金を稼ぐために壊される可能性があり、KDE がそれほど重要だとも思わないし、KDE コミュニティが長期的にフォークを支えられるかも疑わしい
残るのは Electron や、ブラウザコンポーネントに JavaScript/CSS を載せてローカルサーバーコールバックを付ける亜種だが、些細なアプリにもメモリとランタイムのオーバーヘッドが大きいことはさておき、プログラミングモデル自体が悪い
まともなクロスプラットフォーム GUI ツールキットを作るには、ユーザビリティ、アクセシビリティ、デザイン、ドキュメント、テストまで多くの資金と人が必要だ。オープンソースコミュニティはこれを成し遂げられず、GTK は事実上 Linux 専用になっており、Qt や Swing を置き換える現代的な候補もない
TUI は核心的な問題の解決策ではないが、代替案を見ると、クロスプラットフォーム UI のために TUI を選ぶ開発者たちは理解できる。GUI 要求の 80% 程度は、TUI レンダラーを持つ GUI ツールキットでも十分実現できそうだ
そうすれば安定した API と ABI を提供でき、さまざまな他言語から複雑な回避策なしにバインドできる。特にコンパイル言語ではなおさら重要だ
Qt を Python にバインドするのは簡単かもしれないが、Free Pascal のような言語につなぐには C API を露出する中間 C++ ライブラリが必要で、アプリはそのライブラリまで配布しなければならない
残念ながら GUI ツールキットの大半は C ではなく C++ や他の言語で書かれており、開発者が好きな言語でないと使うのが苦痛になる。主流の中で C で書かれているほぼ唯一のものは GTK だが、GTK は適切な下位互換性をほとんど気にしない
ライブラリは C API だけ露出すればどの言語で書かれていてもよいと考えられるが、広く配布されていないものなら静的リンクしたくなることもある。しかし C/C++ 以外ではこれが問題になる
たとえば Lazarus 向けの FLTK バックエンドを作ろうとしたが[0]、FLTK は C++ ライブラリで静的リンクを推奨しているので、スタンドアロン GUI バイナリを作れそうだった
しかし先に C ラッパーを作る必要があり、Linux では g++ がリンカに渡す魔法のフラグなしで C++ ライブラリを非 C/C++ 言語から静的リンクするのが苦痛で、Windows、少なくとも msys2 では不可能だったので諦めた
[0] https://i.imgur.com/W6XbLkr.png
macOS と Windows でネイティブな見た目に非常に近く、Qt よりずっとプログラムしやすい。ユーザーとしても時々プログラマとしても、マルチプラットフォーム GUI では wxWidgets がいちばん好みだ
逆に Electron やブラウザコンポーネントと JavaScript/CSS、ローカルサーバーコールバックの組み合わせは、ユーザーとして本当に嫌いだ。機能を諦めてコマンドラインに戻るとしても、こういうアプリは避けたい
標準的なキーボードショートカットもサポートせず、見た目も妙に浮いていて、予想外のところで引っかかる
TUI フレームワークの中には、ほぼその域に達したものもある。SSH などでほとんど手間なく使える点は良いが、間違った問題を解いている気がする
何でも IDE のように見せたり動かしたりするより、ウィンドウ管理と永続性の部分がもっとまともな tmux のようなものと、より集中的で組み合わせ可能な CLI を使いたい
readline 付きの単純な REPL を作れば、標準的で予測可能な挙動が得られる
それでも、この流れが ターミナルエミュレータの改善 を後押ししている点は気に入っている
見てきた TUI はたいてい NPM 依存 に見える
エージェントたちは、セキュリティ上のタイヤ火災ではない何かで自分自身を書き直す時間すらないように見えて奇妙だ
この手の、あらゆるエージェントが何かを支配するという流れを見ると、結局は十分速くないこと以外は大して結果を心配しなくていい、ゴミ→転換→ゴミのスタートアップ連中が作ったものだと思えてくる
たとえば OpenCode は、今でも全メッセージログを保持し、そのログを同じ順序で SSE エンドポイントに送って次の応答を受け取るという基本すらきちんとできておらず、コンテキスト剪定を無効にしてもプロンプトキャッシュミスが頻繁に出る
開発者体験も素晴らしく、npm も不要だ
curl | bashで回っていた平和なセキュリティの時代よソフトウェア開発者にユーザーインターフェースを設計させること自体が妙だ
テキスト以外のユーザーインターフェースを作る能力がないように見える。配管工に家を設計させたら、配管を通しやすいように床を全部下向きに傾けるだろう、という感じだ
複数のウィンドウを動かしてサイズ変更しなければならないならテキストウィンドウを作り、素早くオプションを選ばせたいならテキストボックスを作り、スタイルや書式付きの文書を素早く書かせたいなら、書式のためにさらに多くのテキストを書かせる
しかも、そのテキストを書式付きの状態で簡単に見られるアプリは作らない
やっていいことであり、使わなければいいだけだ
見た目はきれいだが、アプリスタイル開発やファイルマネージャー程度を超える複雑な作業にはほとんど役に立たない
ターミナルの中で生きる人たちには TUI が向いているからだ
視覚コンテンツによる気の散りがなく、キーボードで極めて効率的で、今では AI がすばやく作ってくれる。昔は本当に苦痛だった
TUI の受け手が増えたので、TUI もより一般的になった
80 桁のテキストの中で、プロダクトマネージャーが単純化できることもほとんどない
どのビッグテック企業もブラウザを捨てない状況こそ、おかしいのではないでしょうか
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 くらいだった