这篇文章介绍 DiffsHub/CodeView（一个在浏览器中展示代码审查 diff 的界面）如何处理极大的 patch，目标是在不牺牲交互的前提下把大量代码变化直接画出来。评论里补充了实现背景：为了保持 120Hz 级别滚动体验，作者尝试了批量读写、延迟 syntax highlighting 以及名为 Inverse Sticky Technique 的滚动方案，而不是单纯依赖常见的 virtualization（只渲染可视区域）。讨论还延伸到 semantic diff（按函数、变量等语义单元显示变化），以及 tree-sitter（代码解析库）和 WASM（WebAssembly）这类用来生成更聪明 diff 的技术路线。有人还提到将其做成 browser extension 以支持 private diffs，说明这个项目不只是展示效果，也在向真实 code review 工作流靠拢。
评论普遍认可这篇文章对浏览器内渲染巨大 diff 的工程拆解，重点在于如何把测量、绘制和滚动都压到足够低的开销。有人强调目标不是让 JavaScript 每一帧追着滚动跑，而是让页面在 120Hz 设备上仍保持原生滚动手感，并用 deferred syntax highlighting、批量读写等方式减少阻塞。也有人明确反对过度依赖 virtualization，认为它会破坏浏览器本身的优化和交互一致性；但另一边也有人指出，在手机、桌面和不同系统上，滚动掉帧依然会明显伤害体验。还有人把这些优化思路迁移到 FreeCAD 的 diff 工作中，说明这套方法并不只适用于源码审查。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
不少评论认为文章如果继续往上层走，讲“怎么决定差异该如何呈现”会比单纯讲文本渲染更有价值。大家举了 whitespace 变化、import 列表换行、函数名替换等例子，指出普通行级 diff 往往会把一次小改动放大成一大片噪音。讨论中提到 semantic diff、difftastic 之类工具，通常会借助 tree-sitter（代码解析库）或语言原生 parser，再配合 WASM（WebAssembly，一种在浏览器中运行的低级字节码格式）来做更结构化的比较。也有人直言，这一类系统比渲染优化更难，是另一条完全不同的产品路线。
除了性能本身，评论还提出了不少面向真实工作流的功能请求。有人希望支持 `git diff --color-moved`，用颜色直接标出移动过的代码块，减少阅读大范围重排时的认知负担。也有人想把 DiffsHub 做成 browser extension（浏览器扩展），这样就能直接查看 private diffs。还有评论把视线放到 Forgejo（一个开源代码托管平台）以及 GitHub、GitLab 之外的生态上，认为这类高性能 review surface 更适合接入更开放的 forge 场景。
也有不少轻松的评论集中在页面本身的视觉细节上，比如有人直接在 DevTools 里改 `main` 的 margin 来修正布局，另一些人则调侃作者一旦把布局做得太“有个性”，就只能靠 reader mode 了。ASCII art 也被反复提起，有人觉得有趣，有人则拿标题区的对齐问题开玩笑，像是在猜这是不是刻意设计。与此同时，许多人只是纯粹表达赞赏，认为文章写得清楚、工具手感很好，甚至读完后开始期待这种高性能工具在更多产品里出现。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
virtualization: 只渲染可视区域来降低 DOM 和绘制开销，但可能牺牲滚动连续性与交互自然度。
semantic diff: 按函数、变量、导入等语义单元展示变化，而不是只按逐行文本比较。
tree-sitter: 一个代码解析库，用来识别源码结构，常被用来生成更智能的 diff。
WASM（WebAssembly）: 一种可在浏览器中运行的字节码格式，常用于把解析器或分析器搬到前端执行。
pretext: 一个用于文本测量与排版的前端库，常被拿来优化大文本的布局和渲染。
Inverse Sticky Technique: 一种用于大文档滚动的技巧，目标是在不让 JS 每帧追滚动的情况下保持原生帧率。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。