先把报表做好，再请人来看
你做了一张每周更新的销售仪表盘。过去，每位同事打开页面，服务器都可能要准备 R 或 Python 环境、读取数据，再把结果送到浏览器。它很灵活，但也像每来一位客人就重新开火做菜：访问速度和维护成本都系在后厨上。
T. Moudiki 在 R-bloggers 介绍的 Observable Framework 换了一个顺序：发布前先运行数据管线，把读取、清洗和整理做完；访问者打开页面时，只接收 HTML、JavaScript 和处理好的数据文件。换句话说，R/Python 仍然干活，只是不再常驻于每次访问的现场。
重活放到构建期
这里的关键是“构建期”——网站发布前的准备阶段。Observable Framework 可以在这一阶段运行 Python、R、JavaScript 或 Shell 数据加载器，并把程序的标准输出保存成 CSV、Parquet 等静态数据文件。浏览器不会运行 Python，只负责下载这些结果。
随后，页面用 Markdown 编排文字，并嵌入“响应式 JavaScript”：当复选框等输入发生变化，引用该输入的代码块会自动重新执行。筛选、排序和绘图因此可以留在浏览器里完成。Observable Plot 则以声明式写法绘图——作者描述想画什么，而不必逐步操纵每个图形元素。
执行 npm run build 后，系统会重新运行数据加载器，生成静态的 dist/ 目录，并给输出加入内容哈希。内容哈希相当于文件版本指纹，可避免浏览器继续使用旧缓存。成品可以放到 GitHub Pages、Netlify 或 S3 这类静态文件托管服务，不需要另养一个应用进程。
“无后端”要加一个定语
据 Observable 2024 年的介绍，创始人 Mike Bostock 将 Framework 称为“Observable 2.0”。这家公司原本以浏览器内的交互式 Notebook 闻名，如今把取数和整理移到构建时，再把数据快照交给浏览器。Bostock 还把这种“程序生成文件，再交给下一环”的方式类比为 CGI 和 Unix pipes。新工具采用的，其实是一种颇老派的分工思路。
它尤其适合一类常见任务：数据按批次更新，读者主要做筛选、查看表格和图表。与典型的 Shiny 或 Streamlit 应用相比，访问者不必现场等待服务器启动、语言会话初始化和运行时取数，加载体验因而可以接近静态网页。不过，这些效果描述均来自作者单一信源，没有提供基准测试或样本规模，不能据此断言它普遍快于 Shiny 或 Streamlit；后两者的实际表现也取决于常驻进程、缓存和部署方式。
局限与未知
- 静态数据通常只更新到最近一次构建。实时查询、即时模型推理或按用户访问数据库，仍需额外后端。
- “访问时无 R/Python 后端”不等于整个系统没有后台设施。定时构建、数据刷新、鉴权和私密数据处理，仍可能依赖 CI、数据服务或服务器。
- 作者展示了一个餐厅小费仪表盘，交互层不足 100 行 Markdown 与 JavaScript，但材料没有给出实测加载时间，也没有说明更大数据量下的边界。