每日突破性工具推薦｜Perry

Perry：把 TypeScript 直接編譯成原生應用的跨平台工具鏈

工具定位

Perry 是一套以 Rust 實作的原生 TypeScript／JavaScript 編譯器與跨平台應用工具鏈。它使用 SWC 解析程式碼，再透過 LLVM 產生原生機器碼；原生輸出不需要在目標機器安裝 Node.js、Bun、Deno 或外部 JavaScript Engine，而是把 Perry 自己的 Runtime 與 Garbage Collector 靜態連結進最終 Binary。

它目前的野心已不只是 TypeScript CLI 編譯器：同一套程式碼可以面向 macOS、Windows、Linux、iOS、iPadOS、visionOS、tvOS、watchOS、Android、Wear OS，以及 Web／WebAssembly，並提供原生 UI、Node.js API 相容層、資料庫與發佈工具。

為什麼今天值得推薦

這次採用近期快速成長且具代表性工具的 fallback。Perry 仍是 pre-1.0 專案，但目前已形成相當完整的 Compiler、Runtime、Native UI、Node Compatibility 與多平台 Target 組合。相較只解決 Server／CLI Binary 的 TypeScript Native Compiler，它正嘗試把 TypeScript 從 JavaScript Runtime 上的語言推向可直接建置 Native Application 的跨平台語言。

突破性重點

1. TypeScript → LLVM → Native Machine Code

Perry 的主要 Pipeline 是 TypeScript／JavaScript → SWC Parse → Perry Compiler lowering／analysis → LLVM IR → LLVM optimization → Native Machine Code → Standalone Binary。這與 Node.js、Bun、Deno 的根本差異，是部署時不再依賴 JavaScript Runtime 執行原始 JavaScript。

2. 不只是把 Runtime 打包進 executable

傳統 Single Executable Application 通常仍把 JavaScript Engine 與應用程式一起封裝；Perry 的主要路徑則將支援的程式結構 AOT 編譯為 Machine Code。官方目前列出的 Hello World 約 330 KB；實際大小則會隨標準函式庫、平台能力與選用功能增加。

3. Tree-shaken Native Runtime

Perry 不把整套 Runtime 無條件塞進每個 Binary，而是依實際使用能力連結必要部分。CLI、Server、Database Client、Native GUI 可以共享同一套 TypeScript 開發模型，但最終 Artifact 不必全部攜帶相同 Runtime Footprint。

4. TypeScript 直接建立真正的 Native UI

Perry 的 UI 層不是 Electron 式 Browser Window。它會將宣告式 TypeScript UI 對應至平台原生 Widget，例如 AppKit、UIKit、Android Views、GTK4、Win32 或 Web DOM；官方目前列出 35+ Native UI Widgets。這讓 TypeScript 有機會直接進入 Desktop／Mobile Native Application 領域，而不是把 Chromium 當成 UI Runtime。

5. 真正的 OS Threads

JavaScript Runtime 傳統上以 Event Loop、Worker／Isolate 與 Message Passing 處理平行運算。Perry 提供 parallelMap、parallelFilter 與 spawn 等原生多執行緒能力，直接使用 OS Threads，並嘗試透過編譯期限制阻止不安全的 Shared Mutable State。這是在把 TypeScript 從 JavaScript Runtime concurrency model 拉向 systems-language concurrency model。

6. Node.js Compatibility 不只是 API Stub

Perry 為多個熟悉的 Node API 提供原生實作，包括 fs、http、http2、net、tls、crypto、stream、child_process、worker_threads 與 Web globals。官方目前追蹤 53 個 Node modules，並表示在其 Node v26 相容性測試中約可通過 97% 測試案例。這些數字仍屬專案自身測試結果，應視為 compatibility indicator，而不是獨立第三方 benchmark。

核心架構與運作方式

Perry 可拆成四層：Application 層承載 TypeScript／JavaScript、npm packages 與 Perry UI／DB／Platform APIs；Compiler 層以 SWC parser、Perry lowering／analysis 與 LLVM code generation 為核心；Runtime 層提供 GC、Native Node-compatible APIs、Platform bindings 與可選的 JS-engine fallback；最後輸出 macOS、Apple 行動平台、Windows、Linux、Android、Web 或 WebAssembly target。

最終 Native Binary 仍包含 Perry Runtime 與 GC，因此更精確的描述是「不需要外部 JavaScript Runtime／Engine」，而不是完全不存在 Runtime。對少數需要真正動態 JavaScript semantics 的情況，Perry 也保留 JavaScript Runtime fallback，並沒有假設整個 npm 世界都能無條件靜態化。

主要優勢

第一，部署模型簡化：Server 或 CLI 可以直接配送單一 Native Binary，不需要另外部署 Node.js 與 node_modules。第二，AOT Native Code 沒有一般 JavaScript Engine 的解析與 JIT warm-up 路徑，對 CLI、短生命週期 Process 與工具程式有吸引力。第三，Artifact Size 有顯著縮小潛力，但大型應用仍會因標準函式庫、Native Bindings 或 Engine fallback 增大。第四，TypeScript 團隊可以把既有技能延伸到原本通常需要 Swift、Kotlin、C#、C++ 或 Rust 的 Native Application。第五，同一 Compiler Stack 同時涵蓋 CLI、Backend、Desktop、Mobile 與 Web，範圍比單純的 Node 替代 Runtime 更大。

相較同類型框架或工具

Node.js／Bun／Deno

Node.js、Bun 與 Deno 都是 JavaScript Runtime；Perry 則希望在可靜態處理的程式上直接產生 Machine Code。因此差異不是單純哪個 Runtime 比較快，而是 Source → JavaScript Engine → Execution 與 Source → LLVM → Machine Code → Execution 兩種部署模型的差異。

Vercel scriptc

scriptc 同樣探索 TypeScript-to-Native，並採用 Typed IR、LLVM 與必要時的 dynamic fallback。Perry 的差異在於範圍更大：除了 Native Compilation，它同時建置 Native UI、多平台 Mobile／Desktop Target、Node Compatibility、Database bindings 與 Application Distribution。scriptc 更接近 Compiler／Node Native Execution 實驗，Perry 則更接近以 TypeScript 為語言的完整 Native Application Platform。

Deno compile／Node SEA

Deno compile 與 Node Single Executable Application 的主要目標是方便配送 JavaScript 應用程式。Perry 的核心差異仍在於 AOT Native Compilation，而不是單純把 JavaScript Runtime 與程式封裝成一個檔案。

Electron

Electron 用 Web 技術換取極高的跨平台 UI 一致性，但代價通常是 Chromium footprint 與較高記憶體需求。Perry UI 直接使用 Native Widgets，理論上能得到更小的 Application Footprint 與更接近平台原生的 UX；代價則是 UI compatibility、生態成熟度與元件數量遠不能與 Web 生態相比。

缺點與限制

Perry 目前只支援實用子集的 TypeScript／JavaScript，而不是完整 ECMAScript dynamic semantics。一般 Runtime Metadata Reflection、任意 Prototype Mutation、user-space dynamic require、eval、複雜 Native Addon，以及高度依賴 Runtime Reflection 的套件都可能無法直接使用。

Legacy Decorator Metadata 也只有部分相容；Angular、NestJS、TypeORM 等高度依賴完整 runtime metadata flow 的框架不能假設能直接移植。npm compatibility 仍遠低於 Node.js；官方列出約 50 個原生支援的熱門 packages，其他純 TypeScript／JavaScript package 可嘗試編譯，但依賴 Node internals、native addons 或高度動態行為的 package 仍可能失敗。

另外 Perry 仍是 pre-1.0 專案。Compiler correctness、Debugger、Profiler、IDE integration、Production observability、ABI stability、第三方 Library ecosystem 與長期 Compatibility Policy，都還無法和成熟 Runtime 或 Native Toolchain 相提並論。因此目前不應把它視為 Node.js、Swift、Kotlin、Rust 或 C# 的普遍替代品。

適合的使用者或專案

• TypeScript CLI 與 Developer Tools
• 需要快速 Cold Start 的小型 Server Binary
• 希望減少 Node Runtime 部署依賴的服務
• TypeScript 團隊開發 Desktop Native Application
• 跨 Desktop／Mobile／Web 的產品原型
• 對 Native UI + TypeScript 有興趣的專案
• 想研究 AOT TypeScript、LLVM 與 Static Compilation 的 Compiler／Runtime 開發者

不適合的使用者或專案

• 大量依賴任意 npm packages 的大型 Node.js 系統
• NestJS／Angular／TypeORM 等高度依賴 Runtime Metadata 的既有應用
• 依賴 Node Native Addon 的服務
• 需要完整 ECMAScript dynamic behavior 的程式
• 對 ABI、Debugger、Profiler 與 Production Support 有嚴格 SLA 的核心企業系統
• 不願承擔 pre-1.0 Compiler Toolchain 風險的團隊

簡短結論

Perry 最值得觀察的並不是 TypeScript 能不能跑得比 Node.js 快，而是它正在挑戰一個更根本的假設：TypeScript 是否一定只能作為 JavaScript Runtime 上層的語言？

如果 TypeScript 能經由 SWC、靜態分析與 LLVM 直接成為 Machine Code，同時取得 Native UI、OS Threads、Mobile Targets 與足夠的 Node API compatibility，那麼 TypeScript 的角色可能從 Web／Server scripting language 進一步延伸為真正的跨平台 Application Language。

Perry 距離成熟 Production Toolchain 還有明顯距離，但它已經把 TypeScript → Native 從單純 Compiler Demo 推進到可以觀察完整 Application Platform 的階段。對 Runtime、Compiler 與跨平台工具鏈而言，這條路線值得持續追蹤。