AI工具Simon Willison23:37
基于 Bun 1.4 新 Bun.WebView 的 shot-scraper 风格 JSON API
A shot-scraper-style JSON API on Bun 1.4's new Bun.WebView
用WebView替代浏览器自动化，成本或降低但兼容性需实测。
判断
Simon Willison 用约 150 行 TypeScript 证明 Bun.WebView 能不靠 Puppeteer、Playwright 起一个 JSON 接口；想砍掉这两个依赖的团队，先按 192MB-256MB 的容器上限和自家真实页面做兼容性实测，再决定拆不拆。
依据
Simon Willison 说，这个零依赖、约 150 行的 TypeScript 服务用 Bun 1.4 实验性的 Bun.WebView（Bun 内置的浏览器自动化 API，可走 macOS WebKit，也可通过 Chrome DevTools Protocol，即浏览器远程调试协议，驱动本地 Chromium 进程）做出 shot-scraper 风格的 JSON 接口：每个请求开一个标签页，/javascript、/screenshot、/healthz 三个端点把页面结果和错误都以 JSON 返回。他用 cgroups（Linux 的资源限制组，这里用来量容器内存上限）测出跑复杂网页要 192MB-256MB 的容器。对照 Bun 1.4 自己的数字——修复 2,900 多个 issue、从 Node.js 测试套件新增 +1,517 条测试、空闲 CPU 降 5x、内存最多降 35%——省下的是依赖与协议栈，代价落在 WebKit 那条路径上：它是官方刚开放的能力，不是被 Playwright 长期压测过的路径。
- 跑复杂页面所需容器192MB-256MB
- 空闲 CPU 占用降低 5x
- 内存占用至多降低 35%
- 新增 Node.js 测试+1,517
没写清 材料只给了单个原型的内存占用，没有同一批真实页面上 WebKit 与 Chromium 两条路径的失败率对照，省依赖之后的兼容性代价有多大，无法替 Simon 补结论。
下一步 在同一批目标页面上，让 Bun.WebView 与现有 Playwright 脚本跑同一条 JavaScript 与截图任务，比对两边的失败率。