重新认识 Datastar：状态留在服务端，前端不写 JavaScript
来源：noteflakes.com — 2026-11-04
📋 概述
作者是 Ruby 后端出身，一开始抗拒 Datastar：没有 JS API、信号是全局的、看起来只适合多页应用。几轮实验后他的态度反转了。Datastar 自称超媒体框架，只用 HTML 属性做声明式交互，靠 SSE 持续把 HTML 补丁或信号补丁推给客户端，不把服务端状态复制到前端再同步。SSE 相对 WebSocket 有两个实在的好处：可以在 HTTP/2、HTTP/3 上与其他请求多路复用，且能享受标准 HTTP 压缩。文中用 Ruby 框架 Syntropy 演示了信号补丁与元素补丁两种写法，并解释了 Instabooks 那种「每次交互整页重渲」为什么能行。
🔑 核心要点
- 库本体约 15KB，只靠 HTML 属性声明交互，不用写 JavaScript。
- 信号在整个页面全局，但可用嵌套对象做命名空间；以下划线开头的信号不会在每次操作时回传服务端。
- 没有 JS API 是设计选择，官方文档明确要求状态尽量留在后端、信号只用于交互与新状态上报。
- 元素补丁要求被替换的节点有稳定 id；信号补丁则直接下发 JSON 键值。
- SSE 相比 WebSocket 可在 HTTP/2、HTTP/3 上多路复用，还能走标准压缩。
- 整页重渲的代价落在服务端，适合渲染快、状态存在 SQLite 这类应用，Rails 那种重框架会比较吃力。
💡 金句
大部分状态应该住在后端，后端应当是你应用状态的唯一真相来源。
👍 0
👎 0
← 返回 Lobsters 首页