Bonsai：Jane Street 的 UI 库

原文 ↗ Hacker News 讨论 ↗

Jane Street 的 Bonsai OCaml UI 库引发了关于一个问题的争论：在 AI 可以基于主流 JavaScript 栈生成定制 UI 的时代，专门化、强类型的 Web 框架是否仍然重要。支持者强调 Bonsai 能在前后端之间共享类型、其受 Elm 启发的增量式状态机模型，以及它同时用于 Web 和终端界面，尤其适合信息密度很高的交易工具。批评者则质疑它出现的时机、视觉完成度、与现有 JS 工具链的生态集成，以及稀缺的文档；而另一些人指出，对于资源深厚的内部团队来说，这些取舍或许是可以接受的。

平台与范围

  • 起初有人误以为它“只支持 Web”；后来澄清说其实也有 Bonsai_term 终端实现。
  • 核心库被描述为一个通用的、增量式的、可组合的状态机框架；Bonsai_web 和 Bonsai_term 分别是面向浏览器和终端的特化版本。
  • 有人询问能否用于 HTML 报告或 TUI；回复称它更适合复杂、交互性强、带状态的 UI，而不是简单的静态报告。

OCaml、生态，以及“前后端同语言”

  • 许多人喜欢前端和后端可以共享 OCaml 类型和逻辑；也有人指出，多年来通过之前的 OCaml-to-JS 方案也一直可以做到这一点。
  • 对比了 js_of_ocaml、Melange，以及其他“编译到 JS”的栈（Scala.js、F#、ClojureScript、KotlinJS、Fable）。
  • 一个反复出现的主题是：将这类栈接入更广泛的 JS 生态需要封装和互操作，而这往往很痛苦。
  • 有人对“在 LLM 时代，通用 UI 库是否还重要”表示怀疑；反方认为，更好的框架仍然能帮助人类和 AI 减少错误。

JS、WASM 与 TypeScript 支线

  • 讨论了 JS 中尾调用优化的限制，以及对蹦床（trampoline）的需求。
  • WASM 被看好，但目前受限于无法直接访问 DOM/Web API，以及下载体积更大。
  • 关于 TypeScript 的争论也出现了：有人说它“只是去掉类型的 JS”，也有人强调某些构造仍然需要编译，而且它依然是一门独立语言。

设计、美学与信息密度

  • 若干评论批评示例 UI 视觉上不够精致，或者“有种 90 年代的感觉”。
  • 也有人强力为高信息密度和少留白辩护，尤其是在交易/金融工作流中，速度和并排比较很重要。
  • 反对观点是：即使对专家用户来说，零边距或不一致的边距也会损害可读性；讨论中突出了新用户可发现性与重度用户生产力之间的张力。

采用、工具与文档

  • 有人担心 bus factor、编译速度、热重载和可维护性；也有人表示 OCaml 编译很快，而且非常易于维护。
  • 相较于 React/Vue，Bonsai 被认为较为冗长，不过有人期待 LLM 能吸收这些样板代码。
  • 还提到了损坏的文档链接以及缺少公开演示页；DOM 更新策略（直接更新 vs diff）也被提出，但没有得到明确回答。
  • 确认其来源公司内部在生产中大量使用；但对于在典型产品团队里作为绿地项目是否合适，仍然存在不确定性。