“Electron might die soon.”
GPUIX 作者 Tommy D. Rossi 丟出這句話時，後面跟著一個很有震撼力的展示：一款用 React 和 TypeScript 寫成的聊天應用，一口氣塞進 5000 則訊息，沒有 Electron，也沒有 WebView，整個介面交給 GPU 繪製。
這句話擺明是衝著話題性來的，但專案本身不是一張概念圖。GPUIX 已經釋出 @gpuix/react 和 @gpuix/native 兩個 npm 套件，截圖當下在 GitHub 拿到約 1.1k Star，最新版本為 0.4.0。
前端開發者最熟悉的 React，這次沒有把元件變成 DOM，而是把介面交給 Zed 編輯器背後的 GPU UI 框架。
這條路如果走得通，Electron 真的會多一個麻煩的對手。
React 這次不渲染網頁了
React 並不只屬於瀏覽器。
我們平常寫下 <div>、useState 和 onClick，最後看到網頁，是因為 React DOM 把元件變化翻譯成瀏覽器能理解的 DOM 操作。React Native 能用同一套元件思維開發行動應用，也是因為它換了一個渲染目標。
GPUIX 做的是同一類事情。它實作了一套 React 自訂渲染器，把 React 產生的介面變更傳送給 Rust：
元件新增時，React 發出 createElement、appendChild；樣式變化時，傳送 setStyle；文字變化時，傳送 setText。Rust 端維護一棵長期存在的元素樹，GPUI 每幀根據它建構暫時元素、計算版面，再把像素畫到螢幕上。
只有發生變化的元素需要跨越 JavaScript 與 Rust 的邊界，不必每次把完整元件樹序列化一遍。
這就是 GPUIX 最聰明的地方：開發者繼續寫 React，應用程式執行時卻不再背著一套瀏覽器。
Node.js 和 Bun 到底幹了什麼
React 和 Node.js 仍然執行在 CPU 上。
React 負責元件狀態、Hooks 和差異比對；Bun 或 Node.js 負責執行 JavaScript；Rust 承接介面樹、視窗和原生能力；真正呼叫 GPU 繪製的是 GPUI。
桌面端透過 napi-rs 把兩邊接起來。專案範例主要用 Bun 啟動，但底層提供的是 Node.js N-API 原生模組，建置需求中也列出了 Node.js 18+。
一個最小應用依然是熟悉的 React 寫法：
import React, { useState } from "react"
import { render } from "@gpuix/react"
function App() {
const [count, setCount] = useState(0)
return (
<div onClick={() => setCount(count + 1)}>
Count: {count}
</div>
)
}
render(<App />, {
title: "My App",
width: 800,
height: 600,
})
看起來像網頁，執行後卻是一個原生視窗。沒有 HTML 檔案，沒有瀏覽器 DOM，也沒有 BrowserWindow。
它甚至支援用 bun --hot 開發。儲存 TSX 檔案後，React 會重新掛載到原本的視窗，GPU 裝置、原生視窗和捲動物理效果都繼續保留。不過這還不是完整的 React Fast Refresh，元件狀態與焦點會重置。
Electron 為什麼又被拉出來「宣判死刑」
Electron 的優勢和包袱來自同一個選擇：把 Chromium 和 Node.js 一起裝進應用程式。
這個選擇給了開發者完整的 Web 平台。HTML、CSS、Canvas、瀏覽器 API、DevTools 和龐大的前端元件生態都能直接使用，macOS、Windows、Linux 的表現也容易保持一致。
代價則是每個應用程式都要帶上一套瀏覽器執行環境。行程更多、安裝檔更大、記憶體開銷更高，也成了開發者反覆吐槽 Electron 的原因。
GPUIX 直接拆掉了中間這層 Chromium：
Electron：React → DOM → Chromium → GPU
GPUIX：React → Rust 介面樹 → GPUI → GPU
鏈路變短，不代表所有應用程式都會自動變快。Chromium 本來就會使用 GPU 做柵格化、合成與動畫，Electron 從來不是「只用 CPU 畫介面」。GPUIX 的變化，是不再為完整 Web 平台付費，只保留桌面應用需要的介面能力。
對於程式碼編輯器、終端機、AI 聊天客戶端、Markdown 閱讀器和 Diff Viewer，這個取捨很有吸引力。這些應用需要高效能文字、長列表、捲動和鍵盤輸入，卻未必需要一整套網頁引擎。
5000 則訊息，能說明什麼
示範中的聊天介面包含 Markdown、程式碼高亮、表格和虛擬化 Diff，捲動時仍能維持很高的幀率。GPUIX 還提供 <virtual-list>，只建構視口附近的行，適合訊息記錄和長列表。
動畫也沒有讓 React 每一幀都參與。React 只傳送一次目標值，後續插值由 Rust 完成，直到動畫結束。這樣能減少頻繁跨越 N-API 邊界產生的開銷。
這些設計都對準了真實的桌面效能問題。
但「5000 則訊息」不能直接翻譯成「效能碾壓 Electron」。虛擬列表的目的本來就是避免同時佈局和繪製全部內容；專案提供了自己的幀耗時迴歸測試，卻沒有公布同一台裝置、同一套介面、同一份資料下與 Electron 的完整對比。
這段示範證明 GPUIX 已經能做出複雜且流暢的介面，暫時證明不了 Electron 應該退休。
真正的問題不是效能，而是生態
GPUIX 現在只有 0.4.0，底層 GPUI 也處在 pre-1.0 階段。Zed 官方明確提醒，GPUI 仍在快速開發，版本之間會頻繁出現破壞性變更。
現階段的限制也很具體：
• 只能使用 GPUIX 已實作的元素和樣式，不是完整的 HTML 與 CSS。
• Ant Design、MUI 和大量瀏覽器元件不能原樣搬進來。
• 巢狀捲動暫不支援，複雜互動仍有不少邊角需要補齊。
• 瀏覽器 WebGPU 版本尚未接通事件回呼。
• Windows 版本仍待執行時期驗證。
• 從原始碼建置需要 Rust，macOS 還要準備 Metal 工具鏈。
• 專案依賴固定版本的 Zed/GPUI fork，底層升級成本還沒有經過長期檢驗。
這也是 Electron 短期內不會「死」的原因。Electron 的價值不只有渲染效能，還有跨平台一致性、安全模型、偵錯工具、無障礙支援、第三方元件和多年累積的工程經驗。
GPUIX 目前更像一台剛點火的賽車。速度看起來很猛，但輪胎、維修站和整條賽道都還在建設。
我的判斷是，GPUIX 最有價值的地方，不是又喊了一次「Electron 已死」，而是讓前端開發者看到了第三條桌面路線。
以前想繼續寫 React，通常就得接受 Chromium 或系統 WebView。現在 React 可以保留，DOM 和瀏覽器卻不再是必選項。JavaScript 負責開發體驗，Rust 負責原生能力，GPU 框架負責把介面畫出來。
Electron 今天當然不會死。
但下一個 Zed、終端機或 AI 客戶端，未必還會從 new BrowserWindow() 開始。