前端圈出了个狠人：5行代码干掉DOM布局抖动

虚拟列表卡成PPT，聊天窗口消息一多就掉帧，富文本编辑器光标乱跳——这些毛病根子上都是同一个 culprit（罪魁祸首）：浏览器布局抖动。有个叫 Basel 的开发者搞了个 LayoutSans，号称用 5 行代码就能让 flex、grid、杂志多栏排版全走计算流，不动 DOM 一根毫毛。

DOM 是性能黑洞，但以前没得选

浏览器渲染管线里，读位置再写样式再读位置，强制同步布局（forced reflow）就像在高速路上急刹车。React Virtualized、TanStack Virtual 这些库再优化，只要还依赖 DOM 测高，就绕不开这个死结。

Pretext 先打了个样：纯数学算文本尺寸，零 DOM 查询。LayoutSans 在这基础上盖了第二层——消费 Pretext 的测量结果，输出完整的二维布局系统。文本节点留在真实 DOM 里，保证屏幕阅读器能读、Ctrl+F 能搜、光标能选；布局计算全在 JS 里跑，帧率稳如老狗。

5 行代码长什么样

README 里的示例确实就 5 行。引入、配模板、扔数据、拿坐标、渲染——完事。没有 `getBoundingClientRect`，没有 `ResizeObserver` 回调地狱，没有 RAF 套娃。

杂志风的多栏排版、聊天消息的流式高度、表格的动态列宽，这些以前要拆成三四个库拼的活儿，现在一个 `layout-sans` 包圆。npm 安装量还在爬坡，但 GitHub 上已经有做富文本编辑器的团队开始试坑。

谁该盯着这个项目

Basel 自己点了三类人：虚拟化 UI、聊天界面、编辑工具。翻译一下就是——Notion 类文档、Discord 类 IM、Figma 类设计工具，所有对「可变高度+流畅滚动」有执念的场景。

有个细节挺有意思：LayoutSans 不碰 DOM 布局，但 DOM 节点是真的。这意味着 SEO 不翻车，自动化测试不用改，渐进增强也天然成立。以前用 Canvas 或 WebGL 做虚拟列表的团队，相当于为了性能把网页的底子扔了；LayoutSans 想证明这条路不是非此即彼。

项目还在早期，benchmark 数据 README 里有，但生产环境的大考还没来。Basel 在帖子里留了话，要反馈，要 issue，要人用。

你手头的项目要是也被布局抖动折磨过，会愿意把核心渲染链押在一个 0.x 版本的新库上吗？