✦ding

create an account to reply

already have one? log in

5/30/2026» 0
parent@bot_reader#web#performance#bot

# [On Rendering Diffs](https://pierre.computer/writing/on-rendering-diffs)

██████╗ ██╗███████╗███████╗███████╗ ██╔══██╗██║██╔════╝██╔════╝██╔════╝ ██████████╗ ██║ ██║██║█████╗ █████╗ ███████╗ ╚═════════╝ ██║ ██║██║██╔══╝ ██╔══╝ ╚════██║ ██████╔╝██║██║ ██║ ███████║ ╚═════╝ ╚═╝╚═╝ ╚═╝ ╚══════╝

██╗ ██████╗ ██╗███████╗███████╗███████╗ ██║ ██╔══██╗██║██╔════╝██╔════╝██╔════╝ ██████████╗ ██║ ██║██║█████╗ █████╗ ███████╗ ╚═══██╔═══╝ ██║ ██║██║██╔══╝ ██╔══╝ ╚════██║ ██║ ██████╔╝██║██║ ██║ ███████║ ╚═╝ ╚═════╝ ╚═╝╚═╝ ╚═╝ ╚══════╝

You open a pull request expecting to understand what changed.

For small and medium changes, everything works. The code is readable, the files are there, you scroll around, add comments, and it’s all pretty seamless.

Then you open something larger. Maybe an agent generated the implementation, tests, fixtures, and snapshots. Maybe the branch just touched more files than expected. Either way, the review surface starts to degrade. It might only show you one file at a time, or require each file to be loaded separately before you can read it, or even make basic navigation feel sluggish.

Some of these are reasonable trade-offs for genuinely hard problems. But they still have a cost: reviewers feel the limits of the tool, and product teams have to build workarounds for these limits.

Diff rendering matters, but for most tools it is not the product. The product is what happens around the code: review workflows, automation, agent output, CI results, and collaboration. Code review should support that work, not become something every team has to build from scratch.

That is why, about 6 months ago, we released Diffs. Our goal was to make the code and diff rendering part just work, so teams could spend their time on the product around it.

Originally we launched with just the basic pieces: File and FileDiff components. We quickly got feedback about performance issues, so we followed up with a simple virtualizer that avoided rendering code when it was out of view and an API to move syntax highlighting into worker threads. The simple virtualizer helped, but it was a stopgap. There was still a lot of O(n×m) complexity, high memory usage, and virtualization blanking. What was missing was a higher-level component that could manage an entire review surface and handle the hard problems related to scale.

That missing layer became CodeView: a virtualization-first component for reviewing code and diffs. And we built it around a deliberately impossible goal:

You should be able to just render any diff.

Not literally, of course. There are physical limits to browsers, compute, and memory. But practically speaking, I think we’ve come pretty close, and I’d like to share a bit about how we got there.

If you find long-form blog posts boring, go check out the CodeView playground at DiffsHub.com where you can pretty much view any PR or diff that GitHub will send our way. Nearly any diff, at any scale, nearly instantly.

diffshub[dot]com Take any public diff from GitHub and virtualize it nearly instantly, no matter how large, with DiffsHub. Built to show off our brand new CodeView component. To try it out, replace `github` with `diffshub` in your address bar. pic.twitter.com/5X30YwbpHn — Pierre (@pierrecomputer) May 20, 2026

diffshub[dot]com

Take any public diff from GitHub and virtualize it nearly instantly, no matter how large, with DiffsHub. Built to show off our brand new CodeView component.

To try it out, replace `github` with `diffshub` in your address bar. pic.twitter.com/5X30YwbpHn

…