【Zig 日报】将我们的 DOM 解析库迁移到 Zig

[jiacai2050]

Migrating our DOM to Zig - Blog | Lightpanda 这篇文章总结了 Lightpanda 团队决定用 基于 Zig 语言开发的 zigdom 替换原有的 LibDOM 实现 的过程和原因。

核心总结点：

1. 替换动机（解决摩擦）： Lightpanda 的代码库由 V8、Zig 层和 LibDOM 组成。原有的三层架构，尤其是在处理事件系统、集成自定义元素（Custom Elements）和 ShadowDOM 时，产生了日益增加的摩擦和不协调性，内存管理和未来多线程支持也存在隐患。团队决定通过替换为自定义的 Zig 实现来获得完全的控制权。
2. zigdom 实现：
   • 经过约六个月的业余时间原型开发，团队构建了 zigdom。
   • 设计上追求精简和内聚，节点（Node）通过一个大的内存块进行一次性分配，而不是进行多次独立分配。
   • 采用延迟加载（lazily parse/load）机制来优化内存使用，只有当 JavaScript 访问特定属性（如 classes、styles）时才进行解析和存储，从而减少每个元素的开销。
   • 核心优势在于提供了更具内聚性的设计，便于处理事件、自定义元素和 ShadowDOM，并为未来增强功能奠定了更简单的基础。
3. 性能提升（次要）： 虽然这次重构带来了个位数百分比（single-digit %）的 CPU 和内存性能提升，但真正的胜利在于代码库的统一和更易于扩展性。
4. 其他技术改进：
   • HTML 解析器更换： 引入了 Rust 编写的 html5ever 作为新的 HTML 解析器，集成过程十分顺利。
   • V8 快照（Snapshot）： 利用 V8 快照功能，在编译时或启动时预先配置 V8 环境并生成二进制快照，从而显著减少启动时间（特别是对于简单页面）。
5. AI 辅助开发： 作者首次利用 AI 编码代理（Claude）辅助完成了这个大型功能开发，认为 AI 在处理有明确规范（如 DOM）的任务时表现出色，但强调这是一个代码审查练习，现有的 CLI 界面在进行复杂审查时仍有不足。

结论： 通过用 zigdom 替代 LibDOM，Lightpanda 获得了对核心浏览器引擎更强的控制力，简化了代码库，并为未来的功能扩展打下了坚实的基础。

加入我们

Zig 中文社区是一个开放的组织，我们致力于推广 Zig 在中文群体中的使用，有多种方式可以参与进来：

1. 供稿，分享自己使用 Zig 的心得
2. 改进 ZigCC 组织下的开源项目
3. 加入微信群、Telegram 群组