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 明确不包含静态编译特性。
什么是 Static Hermes？
Hermes 是 Meta 为 React Native 打造的 JavaScript 引擎——基于字节码、AOT 预编译，为移动端启动时间做了优化。Static Hermes 是将 Hermes 扩展为对类型化 JavaScript 子集进行提前原生编译的研究项目，目的是为 React Native 提供一条通往真正原生代码的路径。`static_h` 分支目前已是该仓库的默认分支，并处于积极开发中，但真正交付给 React Native 用户的是 Hermes V1——一个新的字节码编译器和虚拟机，已于 2026 年 2 月成为 React Native 0.84 的默认引擎——它并不会将 JS 编译为原生二进制文件，也不使用类型信息。Static Hermes 本身仍然是一个编译器研发项目；根据 Perry 的基准测试说明，它目前尚未被打包为可在 macOS arm64 上常规安装的形态（`shermes` 在多语言基准对照中被跳过，并附注说明它“在 Homebrew 或 npm 上没有以可在 macOS arm64 上干净安装的方式提供”——见 perry/benchmarks/README.md）。
什么是 Perry？
Perry 是一个用 Rust 编写的原生 TypeScript 编译器，使用 SWC 解析、LLVM 生成代码。它已交付可用的 CLI（`perry compile`、`perry run`、`perry publish`）、25+ 原生 UI 组件、10 个编译目标、自托管的运行时，以及一个在透明条件下测得的基准套件（M1 Max，RUNS=11）。Perry 仍处于 Pre-1.0，但走的是生产路线：已经有人在用它构建并交付应用（Bloom Engine、Mango、Hone、Pry、dB Meter——见 perryts.com）。
并排对比
| 特性 | Perry | Static Hermes |
|---|---|---|
| 状态 | Pre-1.0（alpha）——走生产路线 | 研究 / 实验性 |
| 安装路径（macOS arm64） | Homebrew、APT、npm（@perryts/perry） | 撰写本文时尚未打包为可干净安装的形式（依据 perry/benchmarks） |
| 后端 | LLVM | 自定义（基于 Hermes 的代码生成） |
| 输入 | 完整 TypeScript | 类型化的 JS/TS 子集 |
| 编译目标 | 10 个：macOS、iOS、iPadOS、Android、Linux、Windows、watchOS、tvOS、WASM、Web/JS | 主要面向移动端（React Native 场景） |
| 原生 UI | 通过 AppKit、UIKit、GTK4、Win32、JNI 提供 25+ 个组件 | 通过 React Native 桥接（在被集成时） |
| 独立 CLI 应用工作流 | 支持——`perry compile main.ts` 直接生成二进制 | 绑定 React Native 上下文 |
| 公开基准套件 | 有——RUNS=11，对比 Node、Bun、Rust、C++、Go、Swift、Java | 内部 / 研究论文 |
Perry 胜出之处
- +它作为一个可用工具是真实存在的。今天就可以通过 Homebrew、APT 或 `npm install @perryts/perry` 安装 Perry，而 `perry compile main.ts` 第一次就能生成二进制。
- +覆盖更广。Perry 可以从一份 TypeScript 代码同时编译出独立 CLI、原生桌面应用、移动应用、手表应用、TV 应用、WASM 和 Web。Static Hermes 聚焦在 React Native 的原生代码路径上。
- +原生 UI 内置。Perry 的 perry/ui 是一套可工作的、SwiftUI 风格的声明式 UI 层，会编译为 AppKit/UIKit/GTK4/Win32/JNI 组件。Static Hermes 把 UI 留给宿主（React Native）。
- +公开、可复现的基准套件，方法论有据可查——perry/benchmarks 给出了 RUNS=11 下针对具名编译器与运行时的中位数 + p95 + σ。
- +LLVM 后端意味着 Perry 直接继承了数十年成熟的优化遍（自动向量化、IndVarSimplify、标量替换），并支持 LLVM 所有目标平台。
Static Hermes 胜出之处
- +由 Meta 支持——拥有可观的工程资源，并以 React Native 作为清晰的战略锚点。
- +Hermes 已经作为字节码引擎在生产中的 React Native 应用里运行；Static Hermes 继承了这套生态与工具链。
- +在 AOT 类型规则与 JS 子集语义上的研究级工作真正具有创新性。
- +如果你已经在 React Native 上，Static Hermes（在可用时）会比改写到另一个编译器是一条更增量的路径。
何时选择 Perry
如果你今天就需要一个能用的 TS 转原生编译器，希望用一份 TypeScript 代码覆盖桌面、移动、手表、TV、WASM 和 Web，或者想要原生 UI 组件而不必依赖 React Native 的桥接，就选 Perry。
何时选择 Static Hermes
如果你已经投入到 React Native，并想要一条从 JavaScript/TypeScript 到 AOT 编译原生代码的移动端路径，并且你能接受站在研究型工具链的前沿，就选择 Static Hermes（在它可用时）。
结论
Static Hermes 是来自一支有信誉团队的、有趣的研究工作。Perry 则是同一类思路下今天可用、可工作的产品，覆盖远不止移动端。如果你现在手里就需要一个 TS 转原生编译器，Perry 是答案；如果你在 React Native 上并愿意持续跟进研究项目，可以观察 Static Hermes。