Perry 项目的核心目标十分明确：将 TypeScript 从“必须依赖运行时才能执行”的语言，推向“能够直接编译出可运行程序”的方向。这个想法听起来有些反直觉，但近期已在开发者圈内引发了广泛关注。
TypeScript 长期以来都是前端开发的标准配置，但它的应用边界正在被不断拓展。名为 Perry 的新方案，给出了一个截然不同的答案：借助 TypeScript 直接编译出原生 App。无需 Node，无需浏览器，也不依赖 Electron 这类套壳方案。这是 TypeScript 首次不仅参与跨平台开发，更试图成为“原生应用的生产语言”。
跨平台开发，其实一直在“绕路”
多年来的跨平台方案层出不穷，但本质上都是在做权衡取舍。
(1) Electron：简单，但代价高昂
本质上是把 Web 技术封装进桌面：JS → Chromium → 应用。好处很明显：开发效率高、生态完善。缺点同样突出：内存占用大、启动缓慢，怎么看都像是一个“披着桌面外衣的网页”。
(2) React Native：贴近原生，但有额外成本
RN 采用桥接路线：JS → Bridge → Native。UI 确实是原生组件，但 JS 与原生之间需要频繁通信。一旦交互复杂，性能和状态管理就会变得微妙。
(3) Flutter：体验稳定，但路线不同
Flutter 直接自行绘制 UI：Dart → Skia → GPU。一致性很好，性能也不错。但它的本质是“自建一套世界”，与系统原生 UI 属于两套体系。
这三条路，本质上都是在想办法让“脚本语言”去适配“原生环境”。而 Perry 开辟了另一条思路。
Perry 在做什么？
Perry 干脆换了一个问法：为什么一定要“运行”TypeScript？能不能直接“编译”？于是它的模型变成了这样：
TypeScript → SWC 解析 → LLVM → Native Binary
编译产生的是一个真正的可执行文件，可以直接运行。这一点至关重要：启动几乎没有延迟，不需要额外环境，发布就是一个二进制文件。项目最新描述也直截了当地写道：
No runtime. No Electron. Just native binaries.
如何快速上手（5 分钟跑起来）
想体验 Perry 的话，门槛其实比想象中低很多。现在推荐的最简方式是通过 npm 直接安装：
npm install @perryts/perry然后编写一个最简单的 TypeScript 文件：
// hello.ts
console.log("Hello Perry");直接编译运行：
npx perry compile hello.ts -o hello
./hello现在，你已经获得了一个真正的原生可执行文件。如果不想安装，也可以“一次性执行”：
npx -y @perryts/perry compile hello.ts -o hello环境要求（很容易踩坑）
有一个点需要特别注意：Perry 依赖系统的编译工具链来生成二进制文件。
- macOS：安装 Xcode Command Line Tools
- Linux：需要 gcc / clang
- Windows：需要 Visual Studio Build Tools
它怎么做跨平台？
很多人第一反应是：“那 UI 怎么办？”
Perry 的做法相当激进——直接使用各个平台的原生 UI。macOS → AppKit，Windows → Win32，Linux → GTK，iOS / Android → 各自原生框架。编写类似下面的代码：
App({
title: "My App",
body: Text("Hello")
})在不同系统上，会被编译成完全不同的实现：macOS 变成 NSWindow、NSTextField，Windows 变成 HWND、系统控件，Linux 走 GTK 组件。最关键的一点在于：这些转换发生在编译阶段，而不是运行时。也就是说，程序跑起来的时候，基本上已经是“纯原生形态”了。
它和 RN / Flutter 的关系
许多文章喜欢把它们放在一起对比，但实际上它们不完全是一个层级的东西。
RN / Flutter 更像“UI 框架”，Perry 更像“语言 + 编译器”。可以这样理解：RN 用 JS 控制原生，Flutter 自己绘制 UI，而 Perry 直接生成原生程序。它更接近 Rust、Go 这一类，而非前端框架。
写在最后
Perry 做的事情很纯粹：把 TypeScript 从“需要运行环境的语言”，向“可以直接生成程序的语言”推进了一步。如果你对跨平台开发感兴趣，不妨亲自试一试。
