Rendering a million-line diff is the easy part. 👀 Comments are what break it. Their height depends on markdown wrapping, expanded details, open reply boxes, and images still loading (none of which you know until you render). Here's how we rebuilt the PR view in the GitHub Copilot app 🧵

Oct 12, 2026 · 6:06 PM UTC

58
17
13
376
96,918
RelevantRecentLikes
A code row is a line at a known height. You can compute the whole geometry up front and never have to correct it. Comments don’t have a predictable height. So we stopped forcing one geometry to serve both, and split the document into two independent height domains.
4
19
7,027
For the first design, we gave every dynamic block a ResizeObserver that wrote measured heights back into the layout. We built it, then rejected it. An observer that writes a height back into the layout it’s watching can retrigger itself, and the cost grows with every mounted block.
1
11
4,122
What we shipped is a recurring measurement pass, gated on idle and scoped to roughly 2400px around the viewport. Mounted blocks are ground truth. Observers normally only flag a block for the pass. They don’t write heights themselves. There’s one exception: a visible block resizing because of the user’s action can apply one synchronous correction before paint. That keeps the comment and code below it moving together without reopening the feedback loop.
1
2
1,873
One bug that held us back was “don’t correct while you’re scrolling.” It was a timestamp guard, and our own programmatic scrolls refreshed it. Toggle the sidebar, and the diff pane changes width. Wrapped lines reflow, and the surface emits a small scroll as it settles. The guard read that as your input and skipped the correction meant to keep your place. The file you were reading drifted off screen.
1
1
1,646
Any “is the user interacting?” check has to distinguish real user input from scrolls caused by your own side effects.
2
4
9,030
Virtualization gets difficult when item height is discovered after rendering. The design needs stable anchors and incremental measurement so late-loading comments do not corrupt scroll position or navigation.
115
XYO
@OfficialXYOOct 14
Even the comment box gets an engineering origin story.
88
This makes huge PRs finally usable
586
variable-height rows are the hard part of virtualized lists, you can't know a height until you render it, so estimating first and correcting after measuring is the usual way through
78
comments breaking layout is the most relatable frontend bug ever
2
614
Variable-height rows are the real enemy of virtualization. Measuring comments after render and fixing scroll position without the page jumping is the hard part. Did you estimate heights first and reconcile, or render off-screen?
376
how did you address the variability of comment heights in rendering?
4
rendering comments adds so much complexity, not just lines in diff
9
the unpredictable comment heights are such an annoying virtualization problem.i've dealt with long PR review threads where expanding one comment shifts everything below it. i'd be curious how the new view preserves scroll position while comment heights are still resolving asynchronously.
26
Rebuilding comments for a million-line diff is seriously impressive.
1
142
holy ai slop post. god damn it cant you have a human write it?
22
nice work! another proof that frontend is not yet entirely left to ai models
93
Lololol GitHub with ai writing their marketing. So tired of ai speak...
32
For the Copilot PR view, I'd test whether a reviewer keeps their place when an image loads or a comment expands above it. Smooth scrolling matters, but losing the exact line you were evaluating adds a different kind of review cost.
68
没有人会审查diff了
2
326
I would love to see the server side of github. You guys must have some crazy activity monitor with ai in effect
146
You already have a commercial subscription, so why are you still posting thread-style short posts? Is it that hard to say everything in one go?
32
as an ex react dev: virtualizing fixed-height rows is a weekend. rows that change height after render (images loading, boxes opening) is the part that eats weeks. do you measure after render, or estimate and correct?
244
keeping my place in the code while a thread expands matters more to me than a perfectly proportional scrollbar
138
A useful regression case here is resizing the pane while an image loads above the viewport. It exercises width invalidation and scroll anchoring together, including the late-loading content that a simple scroll test can miss.
3
Anthony Mongeluzo
@PCS_AnthonyMOct 12
Rendering a million-line diff is the easy part; comments with unpredictable height are what usually break it. Splitting code rows and comments into two height domains is clever engineering.
157
million-line diff: easy. comments: apparently the final boss. the duality of software
116
comments breaking it makes sense, the diff sits still but comments move every time someone pushes. how do you keep a comment on the right line after a force push? that's always felt janky to me
99
说起长文本编辑啊,我前段时间做 LayerFS,才意识到文件存储形式其实就是一串字节,像一个 array。 我在第X行修改,除非字节数相等,否则就会导致X+1行到最后一行搬动。修改的位置离尾行越远,速度越慢。 平时在编辑器里为什么感受不到这种延迟?因为大部分编辑器采用了gap buffer、piece table 或 rope 这类结构,不会每敲一个字就把后面的全部内容搬一遍。 LayerFS 的增量文件构建也用了类似思路:保留没变的内容块和树结构,为修改的部分构建新内容,再更新必要的边界和索引。逻辑上,后面的字节位置变了;物理上,那些没变的内容不一定需要重新写一遍。
65
Dynamic comment heights make large diffs much harder to handle than they seem. Interested to see how the team solved this in Copilot.
140
AI written slop. Can you guys even pretend to make a pathetic attempt to write the post yourself? Or maybe use copilot (and not Claude)?
1
13
418
What are you guys talking about, y'all can't render a million line diff with no comments STFU
3
354
copilot is still as alive? 👀
288
Kiran Kumar G@imkirankumargOct 13
comments breaking layout is so true, you can't know their height until everything finishes rendering
236