背景
TypeScript 已是網頁與伺服器開發的主流語言，但無論程式怎麼寫，最終幾乎都得跑在一個完整的 JavaScript 執行環境上：Node.js 背後站著 V8 引擎，各種替代執行環境也同樣內建整套引擎與龐大的執行期。這帶來兩個長期困擾：一是程式啟動前必須先初始化整個引擎，冷啟動時間很難壓低；二是即使只跑一個簡單的 HTTP 服務，閒置記憶體也動輒數十甚至上百 MiB。Vercel Labs 於 2026 年 7 月 22 日建立、近期公開的實驗性編譯器 scriptc，嘗試從根本改變這件事：它把 TypeScript 直接編譯成原生執行檔，產出的二進位檔裡沒有 Node、沒有 V8，也不內建任何 JavaScript 引擎。專案以 Apache 2.0 授權釋出，這是一種寬鬆的開源授權條款，GitHub 上已累積約四千九百顆星，InfoQ 於 9 月 25 日由 Daniel Curtis 撰文報導。
核心內容
scriptc 的編譯流程分幾個階段。它直接採用真正的 TypeScript 編譯器做語法解析與型別檢查，而不是自己重寫一套前端，這讓語言相容性有基本保障。通過型別檢查後，程式會被降階成一種帶型別的中間表示，再從中間表示產出可讀的 C 原始碼、LLVM IR、組合語言、目的檔、原生執行檔，或透過 WASI Preview 1 輸出 WebAssembly。這裡的 IR 是編譯器內部描述程式邏輯的中間格式，LLVM 則是主流的編譯基礎設施，WASI 則讓 WebAssembly 能在瀏覽器之外的環境執行。
最關鍵的設計是三層處理機制。預設情況下，所有程式構造都被靜態編譯成機器碼；遇到無法靜態處理的部分，例如多數 npm 套件或帶有動態型別的程式碼，可以加上 --dynamic 參數，讓這些程式跑在內嵌於執行檔中的 quickjs-ng 引擎裡，這個輕量嵌入式 JavaScript 引擎約佔 620KB，社群常把這個動態執行區稱為島嶼；至於完全無法處理的構造，會在編譯期直接拒絕，回報 SC 錯誤代碼並附上改寫建議。換句話說，scriptc 並不打算完整模擬 JavaScript 的所有動態行為，而是以型別系統為界線，能靜態編譯的盡量靜態編譯，其餘的明確告訴你怎麼改。
實測數據
官方針對 scriptc 0.0.16、Bun 1.3.12 與 Node 24.18.0 的基準測試顯示，CLI 工具的中位數啟動時間為 1.78ms，Bun 是 21.29ms，Node 則要 61.78ms；一個不依賴框架的 node:http 伺服器，閒置記憶體只有 1.9MiB。啟動速度與記憶體佔用的優勢非常明顯。
但運算吞吐是另一回事。同樣的測試發現，若使用 Hono 這類可在多種執行環境上運行的輕量網頁框架，就必須開啟 --dynamic，結果有 62% 的伺服器程式碼落入 QuickJS 島嶼執行，吞吐量降到每秒約 18,400 個請求，而 Bun 可以達到 70,500 個。Hacker News 上有開發者實測後回報，在位元組陣列操作這種對 scriptc 相對有利的情境下，執行速度仍比 Node 24 慢約 7.5 倍，即使請 AI 助手 Claude 做過針對 scriptc 的最佳化也一樣；不過啟動快了 12 倍（1.5ms 對 18.6ms），記憶體省了 72 倍（2.5MiB 對 181MiB），而且產出的是一個 370KB、無任何執行期相依的單一執行檔。另一位開發者 Remo Jansen 嘗試用 scriptc 編譯 TypeScript 6 編譯器本身，結果在內部編譯器錯誤處失敗；他量到的冷啟動是 3.6ms，遠快於 Node 的 48.9ms，但運算部分要 2.33 秒，明顯慢得多。
技術批評與疑慮
資深 JavaScript 引擎開發者 Filip Pizlo 提出兩點質疑。其一，scriptc 目前所有數字都以浮點數表示，並延後整數型別推斷，等於跳過了打造快速 JavaScript 執行環境一半的問題；其二，依賴 QuickJS 作為動態後備，對一個以效能為訴求的專案並不合適，因為 any 型別在真實程式中太常見，實際應用會不斷掉進那座動態島嶼。社群裡也有開發者表示，手上每個本地專案在型別覆蓋檢查時都產生數百個錯誤，實務上等於不能用；他並質疑，如果必須從零開始寫、不依賴任何第三方套件才能編譯成功，那為什麼不直接選 Rust、Go、Zig、C++、Nim、Swift 這些本來就為編譯而設計的語言。另一個反覆出現的疑慮是專案壽命：Vercel 先前的 zerolang 專案在發表數週後就停止提交，讓人擔心 scriptc 會走上同樣的路。
影響與限制
儘管爭議不少，scriptc 的價值主張依然清楚。Simon Willison 指出，coding agent 一週內就能寫入九十一萬八千行程式碼，而在不寫 C 或 Rust 的前提下產出小而快的二進位檔，看起來是一種很有價值的能力。對 CLI 工具、對冷啟動敏感的 serverless 場景與資源受限環境來說，單一 370KB 執行檔加上毫秒級啟動，確實是傳統 Node 部署做不到的。
實務上有幾件事需要先知道。scriptc 本身需要 Node.js 24 以上才能執行，以 npm install -g scriptc 安裝，文件在 scriptc.dev。它刻意保留了若干與 Node 不同的行為：字串以 UTF-8 儲存、記憶體採引用計數而非垃圾回收、Object.keys 回傳宣告順序、process.argv[0] 是 scriptc。相依套件的行為有專門的 npm dependencies 指南，其中實驗性的 --npm-static 參數可以把指定套件編譯到動態島嶼之外。目標平台涵蓋 macOS、Linux、Windows 與 WASI Preview 1，正確性由差分測試把關，逐位元組比對 stdout、stderr 與結束碼和 Node 的輸出是否一致。官方也明確將 scriptc 定位為實驗性專案，採用前值得先讀過 limitations 頁面。它並不是要取代 Node，而是為啟動速度與資源佔用比運算吞吐更重要的那類工作負載，提供了一條新的路徑。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。