宣布 BABLR

# 宣布 BABLR 来源：https://bablr.org/blog/announcing-bablr 欢迎！我叫 Conrad，职业是前端工程师，过去五年一直在编写开源 JavaScript 代码。我开发了并今天发布了最新版的通用解析器框架 BABLR，以及一个全新的基于 API 的软件开发平台。这个项目的目标是探索：如果 IDE 不再是文本文件编辑器，而是代码文档编辑器，会发生什么？如果我们愿意放下一些历史包袱，我们又能得到什么？其实开发者们每天都在使用文档驱动的编码工具：格式化程序负责缩进，linter 负责捕捉常见错误，转译器负责解语法糖，而 codemod 负责执行涉及数十到数十万个文件的代码重构。今天，我们发布了该平台的核心技术：我们的解析器框架 BABLR——与 Tree-sitter 竞争；一种名为 agAST 的解析树格式——与 ESTree 竞争；以及一种专为解析树设计的新数据语言 CSTML。这些技术都可以独立使用，但组合起来构成了一个深度融合的平台，其整体价值远超各部分之和。BABLR 解析器提供了创建 CSTML 和 agAST 树的能力，而数据结构和算法库则让这些新颖的树格式在实践中变得有用。这个平台能否长期取得显著增长，主要取决于我在语言作者、工具作者和用户之间达成了怎样的妥协——因为最终，这三种人如果能在平台上遇到另外两方，他们就会看到它的价值。因此，讲述这个产品的故事，就是讲述为什么这三个核心群体都会从中获益。 ### 面向开发者的 BABLR 我们认为有多种方式能让开发者爱上我们的平台。我们将其设计为浏览器原生且极其轻量，因此我们的代码分析可以在任何文档网站或博客文章中运行，仅增加约 10KB。我们的语法高亮工具叫 Bedazzlr，它正运行在本页面上，为代码示例提供高亮，例如： ```js let result = /[^^*+/[-][]/.exec("input"); ``` Bedazzlr 所做的不只是其他工具提供的基本令牌着色：它提供了更像 ASTExplorer（https://astexplorer.net/）的体验，直接嵌入到网页中，允许用户通过语义选择和查看嵌入语法树中的节点名称来探究结构。当你在学习一门新语言时，这些名称比颜色有用得多，而且我们能够在前端计算这些名称，也确保我们帮助用户学习新语言的方式不必局限于英语用户。不过 BABLR 不仅仅是花哨的语法高亮器，它还可以成为运行在浏览器中的可视化、触觉化、可编程的代码编辑器的基础。代码编辑器产品 Paneditor 将是第一个从零开始构建、原生支持手机和平板等触屏设备的代码编辑器——因为我们相信下一代人在对编程产生好奇时，手里拿的很可能是这类设备。使用 Paneditor 编写代码不需要用户下载任何软件，甚至不需要对所用设备拥有 root 权限。Paneditor 将具备语义代码搜索和替换等强大功能，所有这些都由今天发布的 BABLR 代码驱动。我们对用户最有力的论据是：这个平台会一天天变得更好，因为我们会不断吸引更多的语言、更多的工具和更多的用户。 ### 面向工具开发者的 BABLR 工具作者关心的是数据收集后的呈现方式。我们在考虑数据方面主要从 XML 生态中汲取了灵感。agAST 是我们用于数据处理的类 DOM API，而 CSTML 是我们用于数据处理的类 SAX API。虽然 CSTML 深受 XML 启发，并且像 XML 一样被设计为基于标签流解析，但我们避免了重复 XML 的错误。CSTML 没有 CDATA 和实体编码，可以用相当简单的解析器来解析。我们甚至比 XML 更进一步：我们的标签流语言对流解析器来说解析起来非常简单。XML 对流解析器来说并不友好，因为 `<![CDATA[` 和 `]]>` 之间存在歧义。由于 BABLR 是流式解析器，而 CSTML 是可流式输出的格式，因此 BABLR 能够在完成完整解析之前就发出部分解析结果。对于只想查询代码的工具来说，使用标签流 API 访问文档结构可能是最优选择，因为这可以避免在开始搜索之前将整个文件内容加载到内存中。这使得开发者能够构建结构化搜索工具，即使文件大到无法装入内存也能正确工作。BABLR 在实践中价值的很大一部分将取决于该平台拥有多少种语言的解析器。在发布当天，数量还很小。我们支持几种自己的语言，然后基本就是 JS 和 Python，而且到今天为止，这两种语言甚至还没有*完全*支持。我采取的做法不是集中精力自己编写大量解析器，而是专注于让编写解析器变得尽可能容易。例如，编写解析器不需要编译步骤，运行的代码就是你编写的代码，并且你可以像使用普通 JS 调试器一样逐步调试。我们还有几个专门用于帮助解析器作者的 BABLR 工具，例如 BABLR CLI，它可以运行解析器，同时输出格式精美的实时跟踪输出，甚至包括正则表达式模式内部的语法高亮。除了工具之外，我们还尽可能让解析器 API 强大，以应对语言设计中棘手的情况。我们支持任意的前瞻和投机执行，以便轻松解析存在歧义的语言。我们支持“移位”来简化解析类似 `2 + 2` 的数学表达式。我个人最喜欢的解析器特性是“守卫范围”（guarded spans），在显式清除之前，它会使得源码在守卫模式匹配的位置处看起来像是结束了。守卫范围使得在 BABLR 中解析带引号的字符串变得非常容易。 ### 留下的空间 这部分是脱稿内容！这部分本不该存在。整个项目，本不该存在。随便问谁，他们都会告诉你新的工具项目应该用 Rust 写，如果代码绝对必须用 JavaScript 写，那至少应该用*TypeScript*写，如果不是 TypeScript，那代码至少应该有成百上千的测试用例。好吧，BABLR 是用普通 JavaScript 写的，而且也没有成百上千的测试用例。我还打破了很多其他规则：我没有使用 monorepo，尽管单一仓库会带来更多流程开销。我的提交信息简直是一团糟，也没有代码审查流程。我没有使用任何形式的 AI，而且我的腕管综合征很严重，工作时必须戴手腕支架。而这项工作本身，恰恰踩了太多重要人物的脚。继承 JS 工具生态的项目名字已经家喻户晓了：应该是 Biome 或 VoidZero，对吧？这些公司似乎没有完全预料到的问题，Josh Waitzkin 在他的《国际象棋大师 2000》教程中称之为“留下的空间”。像 Biome 和 VoidZero 这样的项目，他们决定专注于构建*为*编写 JavaScript 的最快工具。他们的决策表明，工具是否*用* JavaScript 编写对他们来说并不特别重要，而且他们仍然这么想。这对他俩来说都挺好，我也无法反驳任何看起来奏效的策略，然而，他们放弃了用 JavaScript 构建最佳工具这一项目，从而确保了我无需与他们直接竞争。他们的工具期望你坐在一台全尺寸键盘的笔记本电脑前，并且你是 root 用户。而我们发布的工具可以到达任何有浏览器的地方。没有 root 账户？没关系。没有键盘？没关系。他们的工具？每个新版本需要 50-100MB 的下载量。希望你的数据套餐不是太紧张！我们的工具？10-50KB。甚至可以在系统 WebView 中运行。他们的工具为 JS 提供的是二等插件 API，而我们的工具从一开始就把 JS 可扩展性作为一等特性。这已经是很多不同了，还没提到最大的不同：BABLR 支持在发布后通过扩展来支持新语言。Biome 和 VoidZero 都没有这个能力。我们更像 x86；他们更像 Xbox。 ### 情况变得更糟 哦，更糟！CSTML 除了适合作为解析树格式之外（至少在纯技术层面上）是 XML 和 HTML 的自然继承者。什么？！ ### XHTML 当年我开始做 Web 开发时，我们有一个梦想，那个梦想叫做“语义网”。其中一个最有前景的技术是 XHTML，再加上它的捣蛋伙伴 XSLT 作为通往 XML 的桥梁。表面上看这个想法很聪明：不是要求人们为他们的网页编写 XHTML 标记，而是允许他们编写 XML 标记。然后在渲染过程中，XSLT 转换器会将语义化的 XML 输入文档转换为 HTML-XML（XHTML）输出文档。这个想法是，如果你想要一个餐厅菜单，最基本的资产会极其简洁明了，比如这样： ```xml <menu> <category name="Appetizers"> <item> <name>Spring Rolls</name> <price>$3.50</price> </item> <item> <name>Deviled Eggs</name> <price>$3.50</price> </item> <item> <name>Honey Burrata</name> <price>$8.00</price> </item> </category> </menu> ``` 注意，这个菜单文档只涉及一些简单的语法，其他内容就只有餐厅的语言。这里没有 `<div>` 或 `<span>` 标签：没有任何页面布局的语言。这在多个方面都是有好处的： - 当信噪比更高时，文档更容易阅读 - HTML 页面主体最难缓存。缩小它们可以降低托管成本 - 企业不需要仅仅为了更新菜单而请一个 Web 开发者 - 它非常易用，从各个意义上讲 我们还有一个相对于 XHTML 的关键优势：如果没有样式表，你仍然可以渲染 CSTML 文档，因为 CSTML 文档包含内部文本，就像 HTML 一样。上面那个没有经过额外转换的菜单文档会渲染成这样的纯文本： ``` Appetizers: Spring Rolls - $3.50 Deviled Eggs - $3.50 Honey Burrata - $8.00 ``` 与 HTML 类似，当查看菜单的纯文本时，用户可以“检查元素”来查看原始标记。很可能页面作者（一位餐厅老板）在编辑时也会看到文档的源文本形式，就像在浏览器中撰写博客文章的用户可以使用键盘快捷键将某些文字设为斜体，而不必关心浏览器生成了 `<em>` 标签一样，餐厅老板可以通过 UI 添加菜单项，而不必关心底层标记文档中添加了 `<item>` 标签，尤其不必关心诸如菜品名称中的 `"` 需要变为 `\"` 以避免破坏页面源代码等程序员才关心的事情。虽然我们还没有语义页面编辑器，但这篇网页实际上就是用 CSTML 写的！ ### 接下来是什么 我们希望接下来你会尝试使用我们的产品！它是永久免费的，采用 MIT 许可，现在就可以在 NPM 上以 [email protected]（https://www.npmjs.com/package/bablr）的形式获得。在某些方面，这是 BABLR 的终点线，而在某些方面，这还只是起点线。我们已经基本完成的是核心标准：agAST、CSTML 以及 BABLR 语法编写方式。我接下来要投入的工作包括构建语义代码编辑器和对更多语言的支持。我们还成立了一家营利性公司 Silphium Labs，由我和 Stirling Hosstetter 创立，目的是追求这一使命。不过现在很多事情悬而未决。到目前为止，我们的公司没有接受任何风险投资，而我们未来的选择和机会部分取决于社区对这个公告的反应。如果你想对我们的开源工作表示支持，我们欢迎你的反馈、人手编写的代码贡献，或者如果你只是想给我们寄几块钱，因为我们做的东西让你的日子更轻松了，我们接受通过 OpenCollective（https://opencollective.com/bablr）捐款。