Perry 与替代方案对比
Perry 与其他交付 TypeScript 方式的对比：运行时、编译器以及跨平台 UI 框架。诚实、有出处，并在数据存在的地方给出实测数字。
Perry 对比 Bun
Bun 是用 Zig 编写的一体化 JavaScript/TypeScript 运行时、打包器、包管理器和测试运行器，它也可以通过把自身运行时与你的代码打包来生成单文件可执行程序。Perry 走的是另一条路：通过 LLVM 把 TypeScript 直接编译为原生机器码——二进制中没有 JavaScript 引擎、没有运行时，只有一个体积很小的原生可执行文件。Bun 与 Perry 在 TS 转二进制这一点上有重叠，但在“二进制里是否要带一个 JavaScript 引擎”上意见相左。
Perry 对比 Deno
Deno 是一个建立在 V8 之上的现代 JavaScript 与 TypeScript 运行时，原生支持 TypeScript，采用基于权限的安全模型，并提供 `deno compile` 命令——通过把 V8 与应用一起打包来生成单个可执行文件。Perry 则把 TypeScript 直接编译为原生机器码——产物里没有 V8、没有运行时层，只有一个小型的原生二进制。
Perry 对比 Static Hermes
Static Hermes（`shermes`）是 Meta 的一个研究阶段项目，旨在通过 Hermes 引擎对 JavaScript/TypeScript 的一个强类型子集进行提前编译，主要面向 React Native。Perry 押注的是同一个大方向——把 TypeScript 编译为原生代码——但完全独立地用 Rust 在 LLVM 之上构建，如今已拥有一个可用的编译器、25+ 个原生 UI 组件和 10 个正式发布的编译目标。截至 2026 年年中，`shermes` 仍需从源码构建——Perry 的基准测试套件曾尝试将其作为对照对象，却发现没有可通过标准包管理器完成的干净安装路径——而在 2026 年初成为 React Native 默认引擎的 Hermes V1 明确不包含静态编译特性。
Perry 对比 Electron
Electron 让你用 Web 技术（HTML/CSS/JS）构建跨平台桌面应用，方法是把 Chromium 与 Node.js 一起打包进应用。Perry 则把 TypeScript 直接编译为原生机器码，并通过真正的平台组件——AppKit、UIKit、GTK4、Win32、JNI——来渲染 UI。Electron 的卖点是 Web 技术复用；Perry 的卖点是从 TypeScript 出发交付小体积原生二进制 + 原生 UI。
Perry 对比 Tauri
Tauri 是一个用于构建跨平台桌面（以及越来越多移动端）应用的框架，后端用 Rust，前端跑在操作系统内置的 webview 中——Windows 上的 WebView2、macOS 上的 WKWebView、Linux 上的 WebKitGTK。因为不打包系统 webview，Tauri 应用比 Electron 小得多。Perry 走的是另一条路：完全不用 webview，不渲染 HTML，只把 TypeScript 编译为驱动真正平台组件的原生机器码。
Perry 对比 React Native
React Native 让你写 JavaScript/TypeScript 来驱动 iOS 与 Android 上的原生 UI——UI 组件通过 JS 与原生之间的桥（或在新架构下的 JSI / Fabric 层，概念形态相同）映射到平台组件。Perry 走的是另一条路：TypeScript 被提前编译为原生机器码，原生 UI 是编译后二进制的一部分，而非运行时的桥。
TypeScript 的 Electron 替代方案
2026 年 TypeScript 桌面应用的四条现实路径：Electron、Tauri、Bun 单文件二进制，以及 Perry 的原生组件。从二进制大小、内存占用、UI 技术栈和语言等方面进行如实比较。