OpenUI团队将原本基于Rust和WASM的解析器重构为TypeScript实现，以消除WASM边界带来的性能损耗。通过对比测试，新方案显著提升了性能，同时解决了原有流式解析算法中O(N²)复杂度的问题。

从Rust WASM到TypeScript：我们如何让解析器提速3倍

OpenUI工程团队·2026年3月13日

我们最初使用Rust构建了openui-lang解析器并编译为WASM，但最终改用TypeScript重写后性能提升了3倍。以下是关键发现：

解析流程架构

该解析器将LLM生成的自定义DSL转换为React组件树，包含六个处理阶段： 1. 自动补全器（处理流式文本） 2. 词法分析器（生成类型化标记） 3. 分割器（拆分为语句） 4. 解析器（构建AST） 5. 解析器（内联变量引用） 6. 映射器（生成React可用的OutputNode）

WASM边界成本问题

性能瓶颈主要来自JS与WASM之间的数据交换： - 字符串从JS堆复制到WASM线性内存 - 结果序列化为JSON字符串 - JSON字符串复制回JS堆 - V8反序列化为JS对象

尝试使用serde-wasm-bindgen直接返回JS对象反而导致性能下降30%，因为需要大量细粒度的运行时转换。

根本解决方案：完全移除WASM

将整个解析器移植到TypeScript后： - 简单表格解析：9.3µs (原20.5µs) → 提速2.2倍 - 联系表单解析：13.4µs (原61.4µs) → 提速4.6倍 - 仪表盘解析：19.4µs (原57.9µs) → 提速3倍

流式处理优化

通过语句级增量缓存机制： - 缓存已完成的语句AST - 仅重新解析未完成的尾部语句 - 使流式处理复杂度从O(N²)降至O(N)

效果： - 联系表单总解析成本从316µs降至122µs（2.6倍提升） - 仪表盘从840µs降至255µs（3.3倍提升）

WASM适用场景建议

✅ 适合： - 计算密集型任务（图像/视频处理、加密等） - 移植原生库（SQLite、OpenCV等）

❌ 不适合： - 结构化文本解析为JS对象 - 高频调用的小型函数

核心经验

1. 性能分析应优先关注数据传递而非计算本身
2. 直接对象传递可能比JSON序列化更昂贵
3. 算法复杂度优化比语言级优化影响更大
4. WASM与JS内存模型完全隔离，转换必然产生开销

最终方案在单次调用获得2.2-4.6倍加速，流式处理总成本降低2.6-3.3倍。

以下是评论内容的总结，按不同观点分类呈现：

1. 性能提升的关键因素

   • 主要归功于算法优化（O(N²)→O(N)）而非语言选择（评论1）
     "The real win... is the O(N²) -> O(N) streaming fix"
   • 重写代码本身带来的改进比语言更重要（评论3、15）
     "The speedup is not in the language, but in the rewriting"

2. WASM与JS边界问题

   • 消除WASM边界带来2-4x性能提升（评论1）
   • 序列化性能问题存在优化空间（评论6、11）
     "Serializing into JSON on this hot path should be avoidable"
   • WASM在Web生态中的局限性（评论19、20）
     "WASM not being a first-class runtime for the web"

3. 对文章/实现的质疑

   • 基准测试数据不完整（评论13）
     "It never gives us the baseline value"
   • 怀疑AI生成内容导致可信度存疑（评论16）
     "This article is obviously AI generated"
   • 自定义DSL的必要性存疑（评论17）
     "Why is a custom language and parser needed?"

4. 其他观察

   • 网站设计获得好评（评论2）
     "That blog post design is very nice"
   • 公司命名与W3C标准组冲突（评论4）
     "A very confusing name that has been used... for over 5 years"
   • 安全角度的考量（评论18）
     "WASM modules inheriting the host's memory model"

5. 幽默/反讽

   • 建议"再用Rust重写一次"（评论7）
   • 对TypeScript底层实现的调侃（评论8）

关键争议点：
- 性能提升的主因是算法优化（约3.3x）还是WASM边界消除（2-4x）
- 重写代码与语言选择的实际贡献比例
- 技术方案中自定义DSL和二进制序列化的必要性

（注：所有评论评分均为None，故未标注认可度差异）