用 Biff 2.0 搭建 Clojure 项目发现它把 SQLite 设为默认库了

这次 Biff 2.0 的更新逻辑其实挺像现在很多人的开发习惯，不再搞一个巨大的 Monolith 框架，而是把功能拆成一个个独立的库。最直接的体感是 SQLite 变成了默认数据库，配合 Datastar 做服务端渲染，这种组合在做小规模项目或快速原型时速度极快，不用再折腾复杂的数据库配置。

为什么这次要把框架拆散？

Biff 2.0 最大的变化是它现在是一组独立库的集合。我之前试过用非默认数据库的时候，在旧版本里得改很多配置，现在因为它是模块化的，替换掉某个组件的成本低了很多。

这种设计其实是作者在尝试 LLM 驱动编程后的反思。他试过完全不用框架、从零开始写 Clojure Web App，结论是框架依然有价值，但框架应该足够轻量，允许开发者按需组合。这对我们用 Cursor 这种 AI 编程工具的人来说非常友好，因为 AI 在处理单一职责的小库时，产生的 Bug 比处理一个复杂的巨型框架要少得多。

核心组件的实操变化

如果你打算上手 Biff 2.0，有几个关键点得留意：

• 数据层： 默认就是 SQLite。这意味着你跑起来的时候不需要额外部署数据库实例，直接在本地文件里读写。
• 前端渲染： 引入了 Datastar。这东西在 Clojure 社区最近挺火，它主打的是服务端渲染，但能提供类似单页应用的交互感，省去了写大量前端 JS 的痛苦。
• 逻辑组织： 新增了 biff.graph 和 biff.fx。这两个库是用来结构化应用逻辑的。如果你之前觉得 Clojure 的状态管理比较乱，可以用 biff.fx 来规范化副作用的处理。

用 LLM 写 Biff 2.0 代码的经验

虽然作者说 Biff 2.0 主要是手写（虽然有 LLM 草稿），但我在实际尝试用 AI 生成 Biff 代码时发现，由于它现在是独立库结构，Prompt 的写法得变。

不要告诉 AI 「用 Biff 框架写一个功能」，这样它可能会按旧版本的习惯给你写一个大文件。建议把具体的库名喂给它，比如：

;; 告诉 AI 明确使用 biff.graph 来定义业务流
(require '[biff.graph :as graph])

(def my-app-graph
  (graph/graph
    (graph/node :start (fn [ctx] (println "Starting...")))
    (graph/edge :start :next)))

这种明确到库的指令，能让 AI 生成的代码准确率提高很多，因为 context 范围缩小了。

潜在的坑和判断

Biff 2.0 虽然灵活性提高了，但对于完全没接触过 Clojure 的人来说，学习曲线依然在。尤其是 Datastar 的渲染逻辑和传统的 React/Vue 完全不同。

如果你在做以下场景，建议尝试：
1. 个人项目或小工具，需要极速部署，SQLite 足够用。
2. 厌倦了前端构建链（Webpack/Vite），想回归服务端渲染。
3. 想要尝试 LLM 驱动开发，但希望底层架构是确定性的、模块化的。

但如果你需要支撑高并发的大型企业级应用，或者必须使用 PostgreSQL 的高级特性，Biff 2.0 虽然允许替换数据库，但你还是得承担自己配置数据库驱动和迁移的成本，失去了「默认即最优」的快感。