On Rendering Diffs

nit: there is no Linux "v6" or "v7". The first and second version component cannot be separated, it's v6.0 and v7.0. Versions 6.0 and 6.1 have as much in common as 6.19 and 7.0. You could also call them 3.60 and 3.80, or 2.6.100 and 2.6.120.

For anyone else who's suffering, paste this in the console in devtools:

  document.getElementsByTagName('main')[0].style.margin = '0 auto';

What an interesting article. I did not assume I would read it until the end when I opened it, but the writing was super clear and easy to follow.

At the end, I admire the craft and patience to try to solve code diff rendering, and wish the folks at GitHub could put the same effort to improve their platform.

On a side note, I feel that we’re going to see more and more of this type of agentic usage, in well defined sub tasks, and the ability of a model to try many possibilities is a huge gift here.

I don't understand the point of the inverse sticky technique. Scrolling too fast still breaks the experience (content refuses to scroll), and in a way that, at least to me, feels more disruptive than blanking for a fraction of a second. I might just be too used to blanking.

Also ... shouldn't browsers just be able to render the diff without any of the trickery? Is the browser's job actually that hard for long pages, or are they just not optimising for this? Or is there some other reason for the virtualisation (e.g. memory usage)?

It's cool seeing all the engineering that goes into optimizing performance of diffs. I'm working on a FreeCAD workbench that generates diffs on CAD model trees[0], and although my bottlenecks are a bit different, I can still implement some of your optimizations down the line if needed (such as deferred syntax highlighting).

My main bottleneck is that I do a complete diff on all open + changed documents in the repository up front, because due to how document properties are stored, I won't know if the file has meaningful changes until I compute the full diff (FreeCAD may save the document, but not have anything meaningful change.)

[0] https://github.com/eblanshey/HistoryWorkbench

A bit of a technical deep dive into how we built CodeView, a review surface that can handle rendering diffs of immense size, all in a browser.

It is SO NICE to see people working on making fast, nice-to-use tools. It's a lovely experience to use diffshub. Thank you for creating it, and than you for the great write-up! (I made it "that far" )

I was hoping that this would talk more about the logic behind generating a diff, rather than the optimisations involved in rendering the text.

IMO (as someone who doesn't have to deal with the actual rendering) it would go a bit deeper into talking about deciding how to show what has changed. There's a lot of improvements that could be made there. e.g. "whitespace has changed here" so there's no real code changes involved.

Or "this big list of imports has changed, and code formatting has line-wrapped the list into different lines" - gitlab for example copes poorly with this. I'd love to just see a clean diff that highlights the additional import, and not just ten lines of changes caused by adding one line to a big list of imported symbols/functions.

The problem with large diffs is usually with the human, not the computer. Large diffs are very hard to review, so more tools that help with the understanding of a large diff would be very welcome.

I disagree with the theory that scrolling frame rate doesn't need to be smooth for scrolling to feel smooth.

On mobile it kinda does. Scrolling diffs on mobile just kinda feels crap.

I have been spoiled by years of engineer hours spent getting scrolling to be 60- or even 120Hz smooth to match my finger, and diffs just.. isn't.

I know this is frustrating to hear, and that this is technically compounded by mobile probably having the lowest device performance to be playing with too, but.. There you go.

this approach is quite similar to what I use for rendering huge markdown files in https://mdview.io : 10MB files renders correctly and even Table of Content works. 15MB renders but scrolling is not as smooth as I wanted, will work on that. The approach described here https://igorstechnoclub.com/how-i-render-10mb-markdown-files...

Semi-related: have you considered making DiffsHub a browser extension, so you can serve private diffs as well?

(I say this, having done a vibe-port of the code to a browser extension, so the underlying concept works.)

While for "simple" diffs these UIs are "fine", I'm still struggling (after 15+ years of search) for a really good tool that could help me with 3-file diffs...

I'm still stuck with (k)diff3, and, while they work, I would really like to a more integrate web interface for my projects

When producing TreeTrek, I went with rudimentary diffs that account for colourblind developers:

https://repo.autonoma.ca/repo/treetrek/commit/3fe9360599ae23...

The diffs rendering library looks amazing: https://diffs.com/

Presumably the red-green issue is a simple CSS update?

> Safari, for example, currently caps requestAnimationFrame at 60Hz even on higher refresh-rate displays

Of course. It’s often Safari.

This is pretty awesome. I work with editors and monaco-like things a ton, and I review (look at) very large PRs very often. Having this speedy optimized interface is a delight. Check out their trees lib as well.

I remember wrestling with diff tools back in the day. A good visualization can make a world of difference. How does it handle large files with lots of changes?

rendering massive diffs is cool but ultimately a gimmick. in what scenario are you actually reading a 500k line diff?

something i'd really want to see from forges is alternate diff techniques: like AST diffing.

Very impressive! I doubt Github or Gitlab would ever do something as good as this but maybe there's a chance we could get it in Forgejo?

> so hit play on sandstorm

For a brief hopeful moment, I thought this was the .io kind of sandstorm

Whatever happened to all the pretext hype? I feel like that would be perfect for rendering huge diffs.

I feel like virtualization is not the right way to handle things. It adds so much complexity and makes the user experience buggy due to breaking optimizations and features of browsers.

Computers are very powerful these days and have a done of resources that they can use. We should be able to handle large diffs without any crazy tricks.

Maybe an intended effect, but the header ascii art is suspiciously misaligned... :^)

I don’t have much to say except I appreciate the ASCII art.

[dead]

Is this really a hard problem? Rendering some text with coloring?

I believe we're just making everything harder than it needs by constraining it to a browser interface. This would be trivial as a terminal application written in native code.