GeaStack：把 TypeScript 直接编译成原生机器码

JavaScript 生态长期有个”原罪”：跑 TS 应用必须扛着一个庞大的 JS 引擎。GeaStack（品牌 GEA，作者 Armağan Amcalar）想掀桌子——它的 geatsc 编译器把应用代码连同 reactive UI 一起编译成 C++，再由目标工具链编成原生二进制，运行时不需要 Node、也不需要任何 JavaScript 引擎。2026 年 9 月 21 日官方博客抛出一个相当吸睛的标题：“一个 TypeScript 服务器刚刚跑赢了 Rust 的 hyper”。本文基于该官方博客与 one-pager，拆解它到底做了什么、数字怎么测的，以及这些数字该信几成。

一、背景：TS 能不能不靠 VM 跑

TypeScript 传统上要么跑在 Node/V8 上，要么被打包成浏览器 JS。社区也试过用 NativeAOT、Bun 的 WebView 等方式减小体积，但”把整段 TS 连同 node:http 一起编译成机器码”仍属激进路线。GeaStack 的卖点是：同一份 TS 源码，既能在 Node 下原样运行，也能编译成原生二进制；官方甚至说用 raw-socket 测试套件对比两者字节级一致。它的野心不止服务器——one-pager 显示同一条编译链可落到 ESP32 单片机固件、macOS 原生桌面（AppKit 控件）和 Android WebView APK。

二、是什么：geatsc + Gea 编译器插件

编译管线（官方 one-pager）大致是：

• App 源码：Stores、组件、CSS；
• geatsc + Gea 插件：生成 C++ 与 UI bindings；
• 目标工具链：连同运行时与设备 API 一起编译；
• 产物：原生应用或固件。

在服务器侧，关键包是 @geastack/node-compat：它不是”重新实现一个 node:http 的仿品”，而是把真实的 node:http API 和 hono 这个 npm 库本身从 TS 源码编译进同一个二进制。官方称其 node:http 实现在约一千行 C++ 之上、由 TypeScript 编译而来。

三、技术机制与基准

官方基准用的服务器代码就是你写给 Node 的那几行（createServer 返回纯文本与 JSON），用 geatsc 编成原生二进制后，与 Node、Rust（hyper、axum）、C++（Drogon）同台对比。测试方法（官方写明）：一台空闲机器，wrk -t4 -c64、keep-alive、预热后取 8 秒样本，服务端绑两个物理核、压测客户端绑另外两个核以避免争用；三轮交错运行。

图中还有两项：gea · Hono 约 150k、Node.js · Hono 约 41k。官方据此称：4 worker 下吞吐比 hyper 高 14%、比 axum 高 39%、是 Node 的 4.1 倍，内存约为 Node 的 1/49，冷启动快约 20 倍。

四、口径与方法批判：数字很漂亮，但要读完全部小字

这是本文最想强调的一节。官方其实把局限写得很坦白，但标题不会告诉你：

1. 它只打到手写 epoll 环的 86%，而那个参考实现根本不做 HTTP 解析。也就是说，剩下的差距主要来自真实 HTTP 协议处理，这是诚实的参照系。
2. 这是纯吞吐微基准：路由就是 GET / 回固定文本/一个 JSON，没有数据库、没有业务计算、没有序列化到复杂对象。4.1× Node 的优势主要来自”没有 V8 GC、没有 JIT 预热”，一旦接上 DB 与 ORM，差距会被业务 IO 大幅摊薄。
3. 单核结果是双峰的：官方自述单 pin 核上 gea 与 hyper 吞吐相近，且测量呈 bimodal；领先主要体现在 4 worker 多核场景。
4. 可重复性是它自己测的：跨 6 个样本，gea 最低 311.6k、hyper 最高 279.0k，区间不重叠（约 12% 差距），两天内五次完整运行都成立。这增强了可信度，但仍是官方单台机器、自家 harness 的结果，未经第三方独立复核。
5. 生态成熟度：@geastack/* 包 2026 年 9 月才密集发布，支持的是”node:http + hono”这一窄子集；浏览器生态里海量依赖原生 V8/Node API 的库，不可能一夜之间全部可编译。
6. 内存数字有前提：官方特别说明链接 node:crypto 会每个进程多约 0.45 MB PSS（映射了 4.5 MB 库），示例服务器特意没链接它。

五、优势与局限

优势：

1. 同构极客体验：同一份 TS 既能在 Node 跑、又能编译成原生二进制， mental model 统一；
2. 资源占用极低：3.7 MB PSS、6ms 冷启动，对 serverless、边缘、嵌入式场景极具吸引力；
3. 多目标同栈：从 ESP32 固件到 macOS AppKit 到 Android WebView，一套 reactive UI 模型；
4. 诚实的工程细节：连内存怎么省的、单核双峰都写进博客。

局限：

1. 基准是 GET / 微基准，不代表真实 Web 业务性能；
2. 可编译的 API 子集窄，大量 npm 包不可用；
3. 项目极早期，工具链调试、错误信息、社区支持都未经验证；
4. 原生编译链绑定 C++ 工具链，跨平台构建复杂度上升。

六、谁该关注

• 追求极小内存/极速冷启动的边缘与 Serverless 场景：3.7MB、6ms 是 Node 难以想象的；
• 想用 TS 写嵌入式/单片机 UI（ESP32）：这是它最独特的位置；
• 对”编译期消除运行时”有技术兴趣的团队。

但如果你是要跑一个接数据库、接几十个 npm 依赖的常规业务后端，现在就押注 GeaStack 为时尚早——它更像一份激动人心的技术预览，而非可以替换 Node 的生产底座。

八、和同类路线的差异

值得把它放进坐标系里看：Bun、Deno 仍自带 JS 引擎，目标是更快的运行时；GeaStack 走得更远，直接把应用编译成无引擎的原生码。与 scriptc 等”TS→C”方案相比，GeaStack 的差异在于它不只编译函数，而是连 node:http、Hono 这类库一起从源码编译进同一个二进制，并把 reactive UI 与目标设备 API（ESP32、AppKit）打通。也就是说，它瞄准的不是”某段 TS 跑得快一点”，而是”一套 TS 代码同时覆盖服务器、桌面与单片机”的全栈原生叙事。这条路线能否成立，取决于它能把 Node 生态的多大子集编译进来——目前官方只展示了 node:http 与 Hono 这一窄切片。

把它放进观察清单，等更多真实业务基准和第三方复现出来再评估，是更稳妥的做法。

参考来源

• GEA 官方博客：A TypeScript Server Just Outran Rust’s hyper
• GeaStack 官方 one-pager
• npm: @geastack/node-compat
• Koala 项目库条目（原 news_id 1761，页面已迁移）