Internal tool や agent console を作っていると、同じ問題にぶつかることが多い。Data stream は terminal に近いのに、interaction は browser UI と CLI UI に分かれてしまう。Browser 側では log viewer、streaming markdown、tool-call status を作り、command line 側では似た layout、input box、list、table を Ink、Blessed、raw ANSI、stdout helper で作り直す。

今日見るのは Simon-He95/vue-tui。この分裂を Vue 3 component model に寄せて解こうとしている project だ。同じ terminal-style UI model を browser DOM、real CLI stdout、headless tests に render できる。README で想定されている use case は browser terminal dashboards、Vue-powered CLI apps、streaming markdown transcripts、log viewers、virtual lists、AI agent consoles など。

GitHub repository API、README、LICENSE、Languages API、Commits API、Tags API、Releases API を 2026-08-25 18:04 Asia/Shanghai 時点で確認すると、Simon-He95/vue-tui は 230 stars、10 forks。主要言語は TypeScript で、Languages API には少量の JavaScript も出ている。License は MIT。Repository created time は 2026-04-30 16:01:22 UTC、latest public push は 2026-08-25 09:42:25 UTC、default branch は main。GitHub Releases API には latest release がなく、Tags API で見える最新 tag は v0.0.8。package.json の npm package name は @simon_he/vue-tui、version は 1.1.6。Install は pnpm add @simon_he/vue-tui vue、Vue peer dependency は >=3.3.0 <4、CLI/runtime consumers は Node.js >=16.17 を support する。

プロジェクト概要

項目内容
リポジトリSimon-He95/vue-tui
位置づけVue 3 terminal UI toolkit。DOM、CLI stdout、headless tests を support
Stars230
Forks10
主要言語TypeScript
ライセンスMIT
作成日時2026-04-30 16:01:22 UTC
Latest push2026-08-25 09:42:25 UTC
Default branchmain
最新 ReleaseGitHub Releases API には latest release なし
最新 tagv0.0.8
Current package version1.1.6
Installpnpm add @simon_he/vue-tui vue
キーワードVue、terminal UI、DOM renderer、CLI、markdown、logs、agent console

Terminal UI は terminal の中だけに閉じなくていい

vue-tui の core idea は、terminal-style UI を runtime ではなく information layout として見ることだ。多くの tool には terminal 的な密度と継続出力が必要になる。Build log、agent transcript、search result、task list、status table、streaming markdown response。だが、それらは shell の中だけに出るわけではない。Browser の debug console、admin panel、internal dashboard、agent playground にも出てくる。

Web と CLI を別々に model すると、重複はすぐ増える。List、input handling、status display、markdown rendering fallback が二重になる。vue-tui は Vue component を共通言語にする。TerminalProvider が buffer、DOM renderer、event manager、scheduler、input plugins を扱い、TBox、TInput、TList、TTable、TText などの components で terminal surface を記述する。CLI 側では createTerminalApp、createStdoutRenderer、stdin driver を使い、同じ考え方を real stdout に接続する。

この設計はすべての app に向くわけではない。普通の form、admin CRUD、landing page に terminal abstraction は不要だ。だが product の中心が command output、log stream、agent session、developer console なら、shared model は効く。Browser で layout と interaction を調整してから core component を CLI に持っていくこともできるし、先に CLI tool を作り、あとで browser console を足すこともできる。

agent console に効く理由

最近の agent UI の難しさは、文字を表示できるかではなく、状態が細かく分かれすぎることだ。ひとつの agent run には user input、model output、tool call、file diff、error、reference、markdown、progress、log、次の input box が混在する。普通の chat bubble に詰めると余白が増えすぎる。Raw terminal output だけだと selection、link、folding、virtual list、structured status を保つのが難しい。

vue-tui の README は agent console を showcase として扱い、@simon_he/vue-tui/agent を experimental entrypoint に置いている。Agent output、markdown content、tool-call status、input chrome をひとつの terminal surface に stream できる、という方向だ。これは実用的だ。Agent は純粋な chat でも traditional REPL でもなく、append-only で、部分的に interactive で、高密度に読む workspace だからだ。

重要なのは、project がすべてを root import に入れていないことだ。README は stable surface と experimental surface を分けている。Root entrypoint は browser-safe terminal core、DOM renderer、stable Vue components、input host plugin factory を持つ。CLI-only APIs は /cli、markdown は /markdown、agent aggregation、virtual list、transcript view、log view、charts、3D、video は /experimental または /agent。若い UI toolkit では、「全部 stable」と言い切るより、この boundary のほうが信用しやすい。

Entry points の boundary が分かりやすい

この project の entrypoint 設計は読みやすい。README は、何が public、advanced、experimental なのかを表で示している。@simon_he/vue-tui は browser-safe な stable entry。/core は buffer-facing types、ANSI/theme/path/hyperlink helpers。/renderer/dom は DOM renderer。/cli は Node-only runtime、stdin driver、stdout renderer。/markdown は streaming markdown block sources。/mermaid は optional Mermaid bridge だ。

これは terminal UI library でよく起きる host capability の混乱を減らす。Browser は link を開けるし DOM event と CSS を使える。Terminal は OSC8 hyperlinks、stdin、stdout、terminal graphics protocol を使う。Headless tests は real terminal なしで動いてほしい。vue-tui は entrypoint で能力を分け、どの import が Node-only や experimental constraint を持つのかを見えるようにしている。

README は link safety も細かく書いている。DOM renderer の link rendering は opt-in。CLI/stdout では default で safe な https:、http:、mailto: の OSC8 hyperlinks だけを出す。file: URL は terminal-specific opt-in が必要。Developer tool ではこれは小さな detail ではない。Agent console は model output、log、remote repository 由来の string を link に変えがちなので、link policy が曖昧だと security boundary も曖昧になる。

改善できそうな workflow

一つ目は internal developer panel だ。Browser 上の build panel を考えると分かりやすい。左に task list、中央に append-only log、右に failure summary と retry input がある。普通の Web UI でも作れるが、core experience が terminal-like output なら、TBox、TList、TTable、TLogView のような components は普通の div より問題に近い。

二つ目は CLI app だ。Vue ecosystem の developer が TUI を書きたいとき、慣れた reactive model を捨てたくないことがある。vue-tui は component、state、event handling を Vue の考え方に残し、その出力を stdout renderer へ流す。React developer が Ink で CLI を書く動機に近いが、Vue 側の選択肢になっている。

三つ目は agent transcript だ。Agent run は長い list になり、しかも追加され続ける。README が virtual lists、append-only logs、streaming markdown、agent transcripts を挙げているのは、長い session で一番壊れやすい部分を見ているからだ。Virtualization と streaming markdown が同じ terminal buffer model の上で動くなら、textarea、pre、markdown renderer、scroll hack を貼り合わせるより保守しやすい。

四つ目は documentation と test だ。Headless tests を target renderer のひとつにしているので、component が real terminal や browser screenshot だけに依存しなくて済む。Terminal rendering は width、ANSI、Unicode、resize、selection の細部で壊れやすい。人間の目視だけで確認するより、testable な renderer を持つほうが長期保守には向いている。

最近の maintenance signal

Commits API では、最新 commit は af238f5、commit time は 2026-08-25 09:42:25 UTC。内容は TUI に interactive terminal browser を追加し、review finding の修正と agent console profiling の安定化を含む。ひとつ前のまとまった commit は 2026-08-13 で、terminal image rendering の最適化、graphics placement、profile gate などがテーマだった。README だけの project ではなく、terminal graphics、agent console performance、examples を継続的に触っていることが分かる。

Repository には 709 commits があり、file tree には docs、examples、e2e、test、apps、terminal-flappy-bird、terminal-nes などが見える。ここにはかなり experimental な匂いもある。Terminal で 3D、video、NES、Flappy Bird を動かす必要がある business app は少ない。ただ、この手の example は renderer、input、graphics protocol、performance boundary を強く試す pressure test にもなる。Terminal UI toolkit では、大げさな example が rendering system の問題を見つける役に立つことがある。

どう試すか

Vue project で browser terminal panel を作りたいなら、README の browser usage から始めるのがよい。@simon_he/vue-tui と vue を install し、TerminalProvider で固定 cols/rows の surface を包み、TBox、TText、TInput、TLink などを置く。まず output、input、link を動かし、その後で log virtualization、markdown、agent transcript を足す。

本物の CLI を作るなら /cli entrypoint を見る。createTerminalApp で Vue component を mount し、createStdoutRenderer を stdout に接続し、stdin driver で input を処理し、exit 時に cleanup する。これは DOM app を terminal にそのまま移すものではなく、Vue component model を terminal buffer と stdout renderer に接続するものだ。

Agent console が目的なら、/agent と /experimental はまず experiment layer として扱いたい。Core panel は stable root、/cli、/markdown に寄せ、agent-specific aggregator は薄い wrapper に閉じ込める。API が変わったときの migration surface を小さくするためだ。

Caveats

第一に、project はまだ若い。Repository は 2026-04-30 作成で、現在 230 stars。Package version は 1.1.6 だが、GitHub Releases API には latest release がなく、Tags API でも v0.0.8 だけが見える。Release process と semantic versioning policy はまだ観察が必要だ。

第二に、魅力的な機能の多くは experimental または agent entrypoint にある。3D、video、charts、virtual list、transcript、log view、agent aggregation は面白いが、production app で使うなら import boundary を隔離し、experimental API を business code 全体に広げないほうがいい。

第三に、terminal graphics protocol には現実的な制限がある。README は、kitty または iTerm2 なら pixel-level graphics output を得られ、graphics protocol がない terminal では ASCII に degrade すると説明している。Linux arm64 / musl では Bun-only WebGPU renderer の prebuilt binary がなく、source build が必要になる。Cross-platform CLI として配る前に、target terminal で実測する必要がある。

第四に、Vue が前提になる。React、Solid、Svelte、pure Go/Rust TUI ecosystem にいる team が Vue component model に移る価値があるとは限らない。vue-tui が一番合うのは、すでに Vue が好きな team、または Web terminal panel と CLI app を同じ UI language に寄せたい team だ。

まとめ

Simon-He95/vue-tui が面白いのは、TUI を「terminal の中の UI」に限定せず、terminal-style interaction を Vue component surface として扱っているところだ。Browser DOM、real stdout、headless test、markdown transcript、log view、agent console が同じ terminal buffer と component model の上に乗る。

まだ若く、experimental surface も多いので、production に無条件で入れる段階ではない。それでも agent console、internal log dashboard、Vue CLI app、Web panel と command line interface の共有を考えているなら、vue-tui は試す価値がある。解いている問題は「terminal は格好いい」ではなく、「同じ developer workspace を Web と CLI で二重実装したくない」ことだ。

リポジトリ：https://github.com/Simon-He95/vue-tui