On Rendering Diffs

amadeus

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.

cipherself

For anyone else who's suffering, paste this in the console in devtools: document.getElementsByTagName('main')[0].style.margin = '0 auto';

IshKebab

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?

joosters

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.

logdahl

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

shaokind

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.)

nerdypepper

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.

cvince

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

akdor1154

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.

brap

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

tomtom1337

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" )

darkamaul

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.

eblanshey

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

charcircuit

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.

thangalin

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?

philsnow

> so hit play on sandstorm For a brief hopeful moment, I thought this was the .io kind of sandstorm

archargelod

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.

gloria_mundi

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)?

andrew_kwak

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?

lxe

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.