Theo 深入分析了 Claude Code 使用 React 和 Ink 進行終端渲染所引發的爭議。他解釋終端渲染與瀏覽器 DOM 的根本差異、標準緩衝區與替代模式的取捨，以及 Anthropic 團隊為何選擇 React 作為 CLI 框架。影片不只是技術解析，更揭示了一個重要的工程哲學：有時候選擇「夠好」的技術、在需要時再重寫底層，比一開始就追求最佳效能更務實。

---

原影片連結：https://www.youtube.com/watch?v=xrio-BsgkqU

影片重點

• Claude Code 的終端渲染使用 React + Ink，引發社群關於效能的激烈討論
• 終端渲染比瀏覽器 DOM 更慢，因為所有更新都是透過追加文字完成的
• 標準緩衝區（Standard Buffer）和替代模式（Alt Mode）各有利弊，Claude Code 選擇標準緩衝區
• React 的 Virtual DOM 模型在終端中會產生大量 ANSI 跳脫字元，導致效能瓶頸
• Anthropic 團隊已 fork Ink 並加入原生元件，持續優化渲染管線
• 選擇 React 的核心原因是團隊協作效率，而非極致效能
• Boris（Claude Code 創建者）的工程哲學源自 Meta：先快速交付，再重寫底層
• 未來趨勢可能是從終端 UI 轉向獨立桌面 UI 應用程式

詳細內容

[00:00] 事件起因：一則推文引發的風暴

Anthropic 的 Claude Code 工程師 Thariq 在 Twitter 上分享了他們如何修復 Claude Code 的畫面閃爍問題。文中提到 Claude Code 的渲染管線類似小型遊戲引擎：每一幀需要透過 React 建構場景圖（Scene Graph）、佈局元素、光柵化到 2D 畫面、與前一幀做差異比對，最後生成 ANSI 跳脫序列寫入終端。他們只有 16 毫秒的幀預算，其中 React 場景處理就佔了 11 毫秒，只剩 5 毫秒來完成 ANSI 寫入。

這段描述引發了大量批評，有人諷刺說：「我們居然活在一個用 React 驅動簡單 TUI、需要 11 毫秒來排版等寬字型文字的荒謬世界。」

[02:48] React 的渲染模型回顧

Theo 從基礎開始解釋 React 的運作方式。在 React 出現之前，開發者需要手動選取 DOM 元素並綁定行為——找到按鈕、綁定點擊事件、手動更新對應的顯示元素。React 顛覆了這個模式：將狀態放在首位，用 useState 管理資料，當狀態改變時，整個元件重新計算。

React 的核心大膽決策是：與其手動追蹤哪些元素需要更新，不如讓所有東西都重新計算，然後透過 Virtual DOM 差異比對來找出真正改變的部分，只把差異提交給瀏覽器。這個技術讓開發變得簡單許多，但前提是「提交變更」這個動作要夠快。

[05:48] 終端渲染為什麼比瀏覽器更難

有人問 Boris 為什麼不直接全部重繪而要做差異比對，Boris 回答：「終端比 DOM 慢得多。」這是一個讓很多人驚訝的事實。

終端的標準緩衝區是一個純粹的追加系統——所有輸出都是一行一行往下寫。如果你想回頭修改之前的內容，就必須使用 ANSI 跳脫字元告訴終端「跳回某個位置再修改」。這意味著每次更新都在增加需要傳送的資料量。歷史越長，跳脫序列越多，效能就越差。加上顏色、樣式等特殊字元，資料量會快速膨脹。

相比之下，瀏覽器的瓶頸在於追蹤和更新的元素數量；而終端的瓶頸在於推送的位元組數量。這是完全不同的效能特性。

[08:30] 標準緩衝區 vs 替代模式

終端有兩種主要的渲染策略：

標準緩衝區（Standard Buffer）：所有輸出追加到滾動歷史中。Claude Code 使用這種模式，所以你可以選取文字、捲動查看歷史。但每次關閉 Claude Code，整個對話歷史會被寫入終端的滾動緩衝區，需要大量額外文字來覆寫舊內容。

替代模式（Alt Mode）：完全接管終端畫面，不寫入滾動歷史。Open Code 使用這種模式，所以關閉後什麼都不留。但代價是必須自己實作文字選取、複製貼上等功能。

Theo 實際展示了兩者的差異：Claude Code 關閉後歷史仍在、可以正常選取文字；Open Code 關閉後畫面消失、選取行為需要自訂邏輯。這是一個核心的架構取捨。

[12:30] 視窗大小調整的挑戰

Theo 展示了不同工具處理視窗調整大小的差異。Claude Code 能正確地重新渲染所有內容，包括之前的歷史記錄，因為 React 的 Virtual DOM 會持續比對並修正差異。相對地，Codex（OpenAI 的 Rust CLI）使用標準緩衝區但不重新渲染已輸出的內容，所以當視窗縮小再放大時，之前的文字排版不會修正。

終端甚至沒有原生的「視窗大小變更」事件（不像瀏覽器有 window.onresize）。Claude Code 團隊推測是透過攔截 SIGWINCH 信號、暫時切換到替代模式來偵測視窗尺寸，然後重新計算佈局再切回來。這些都是需要手工處理的底層細節。

[16:15] 為什麼選擇 React 和 Ink

Ink 是一個將 React 帶入 CLI 世界的專案。它使用 Yoga（Meta 開發的跨平台 Flexbox 佈局引擎）來計算元素位置，然後生成對應的 ANSI 跳脫序列來渲染。這讓開發者可以用熟悉的 React 元件和 Flexbox 語法來構建 CLI 介面。

React 的最大優勢在於團隊協作：元件的隔離性讓一個開發者很難因為修改底層元件而意外破壞上層功能。這種「由上而下」的思維模式消除了整個類別的同步 bug。相比之下，其他框架如 Svelte 或 Solid 更容易因為信號綁定錯誤而導致狀態不同步。

[19:20] Boris 的 Meta 式工程哲學

Claude Code 的創建者 Boris 曾在 Facebook 工作，負責將大量程式碼遷移到 React。Theo 認為 Boris 帶來了 Meta 獨特的工程哲學：不是繞過問題或在問題之上建構，而是深入問題底層重新改造。

Meta 的經典案例包括：

• PHP 太慢但程式碼庫太大 → 不重寫 Facebook，而是重寫 PHP（創造了 Hack 語言和 HHVM）
• React 有效能問題 → 不換框架，而是寫 React Compiler 自動優化所有程式碼
• JavaScript 在行動端太慢 → 打造 Static Hermes 將 JS 編譯為原生程式碼
• 他們甚至拒絕使用 Git，改用自己 fork 的 Mercurial（後來演變成 Sapling）

Boris 對 Claude Code 的思路很可能是：React 也許不是技術上最優的選擇，但如果出了問題，可以重寫底層基礎設施來解決，而不是重寫整個應用程式。事實上，Anthropic 收購 Bun 也符合這個邏輯——這和 Meta 重寫 PHP 是完全相同的思維模式。

[23:50] Claude Code 的現狀與演進

Claude Code 最初是一個實驗性產品。如果失敗了，技術選型都不重要。但它成功了，現在是時候處理技術債務。團隊已經不再使用原始的 Ink，而是進行了大量 fork 和原生化改造。

其中一個具體問題是：渲染緩衝區中的文字量越來越大，導致垃圾回收更頻繁，每次 GC 就可能掉一幀。社群中也出現了像 Claude Chill 這樣的第三方工具，透過代理攔截來過濾掉不必要的螢幕重繪，減少發送到終端的資料量。但這種方案也有代價——捲動行為會改變、調整大小時可能出現閃爍。

[27:00] 終端 UI 的未來

Theo 坦言他越來越傾向於離開終端 UI。他最近常用 Conductor（一個 Claude Code 和 Cursor 的獨立 UI 客戶端），因為它提供了真正的圖形介面——可以點擊切換、Command+Tab 切換視窗、同時管理多個專案。

他認為終端本質上不是為 UI 設計的。即使有像 Textual 這樣令人驚嘆的 Python 終端 UI 框架能在終端中渲染複雜應用，但只要涉及視窗調整、文字選取、剪貼簿操作，問題就會浮現。這也是為什麼 Open Code 也在開發桌面應用版本。

不過 Theo 強調，Claude Code 在日常使用中仍然完全可用。偶爾的延遲確實存在，但並不影響主要工作流程。那些在 Twitter 上大聲抱怨的人，很多並不是真正的日常使用者。

我的想法

這部影片最有價值的地方不是技術細節本身，而是它揭示的工程決策思維。在技術社群中，我們常常陷入「最佳技術方案」的迷思——一定要用最快的語言、最輕量的框架、最新的範式。但 Boris 和 Meta 的哲學提醒我們：技術選型從來不只是效能比較，還要考慮團隊規模、開發速度、可維護性，以及「錯了能不能改」的彈性。

另一個值得注意的觀點是終端 UI 的天花板。隨著 AI 編碼助手越來越複雜，需要顯示差異比對、多面板、即時預覽等功能，純終端方案的限制會越來越明顯。Conductor、Open Code Desktop 這類獨立 UI 的出現很可能是趨勢，而非曇花一現。對開發者來說，理解這個轉變可能比糾結於「該用 React 還是 Ratatui」更重要。