Perry 与替代方案对比
Perry 与其他交付 TypeScript 方式的对比：运行时、编译器以及跨平台 UI 框架。诚实、有出处，并在数据存在的地方给出实测数字。
技术事实和测量说明以英文为准，以避免不同翻译之间出现偏差。
Perry vs Bun
Both can produce a single executable, but the contents differ. Bun bundles the application with a copy of the Bun runtime. Perry compiles supported code to native machine code and statically links its own runtime and GC without a JavaScript engine by default.
Perry vs Deno
Deno compile produces a standalone executable by bundling a slimmed-down Deno runtime with the program. Perry compiles supported code through LLVM and does not include a JavaScript engine by default, while statically linking its own runtime and GC.
Perry vs Static Hermes
Perry and Static Hermes both explore ahead-of-time JavaScript/TypeScript compilation, but they have different runtimes, toolchains, target goals, and maturity. Static Hermes remains an active branch of the Hermes project; Perry ships a pre-1.0 CLI and platform stack.
Perry vs Electron
Electron embeds Chromium and Node.js and renders application UI as web content. Perry compiles supported TypeScript through LLVM and maps its UI model to platform widgets where supported. Electron is more mature and web-compatible; Perry targets a different UI and deployment model.
Perry vs Tauri
Tauri combines a compiled Rust core with HTML, CSS, and JavaScript rendered in an operating-system webview. Perry compiles supported TypeScript through LLVM and maps Perry UI to platform widgets. Tauri benefits from web frontend compatibility; Perry targets a no-webview UI model.
Perry vs React Native
React Native normally runs JavaScript through Hermes and renders host-platform views through its renderer and native-component system. Perry compiles supported TypeScript through LLVM and statically links its runtime and GC. React Native is much more mature; Perry offers a different AOT and target model.
TypeScript 的 Electron 替代方案
2026 年 TypeScript 桌面应用的四条现实路径：Electron、Tauri、Bun 单文件二进制，以及 Perry 的原生组件。从二进制大小、内存占用、UI 技术栈和语言等方面进行如实比较。