Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use.

Also this works in all browsers, fixing blink doesn’t help move the web forward.

Glad we solved glitchy scrolling for now (the title of this blog post was “on rendering diffs”, not “searching diffs”). Browser search on a 36 million line diff would not by great, but it’s something we hope to have a solution for. One step at a time.

If the solution for searching big pages was built into the browser then it would be fixed for every site instead of requiring each site to use a library or fix it themselves.

Appreciate it, thank you!

Hey thank you, appreciate your kind words! I don’t write much and was quite an effort to get all this written out!

I probably didn’t explain this well enough, but your render times always have to be within the frame buffer (16.6ms for 60hz or 8.3ms for 120hz). Under normal circumstances even if you occasionally blow a frame buffer, with the over-scroll you won’t hit the sticky bounds.

The only time you will is if you’re scrolling at a rate where the jumps are quite large — large and fast enough typically where you’re not going to have a frame of reference for what you should see vs what you are seeing to notice you are behind.

Ultimately scrolling is managed on a separate thread from JS, which means if you do like an opt+click on the scroll bar, you’re going to make a jump that JavaScript can never keep up with, even if you’re under your frame times.

And with regards to safari, if your requestAnimationFrame is capped at 60hz but your scrolling is GPU composited at 120hz, this is the only way to keep scrolling at 120hz with 60hz dom updates and never see any blanking.

Yeah, my bad. Sorry i wasted your time :(

Yup! You can pick from a bunch of different themes and use css variables to override the core colors as well!

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

It's possible you might be misunderstanding what I was trying to say here because 120hz scrolling on a 120hz device was the goal and why one of those virtualization techniques was not acceptable to me which lead me to coming up with a novel workaround to this problem (Inverse Sticky Technique).

CodeView uses a system that allows scrolling to update at your native framerate (120hz) WITHOUT needing Javascript needing to keep up at 120hz. If you're seeing stuttering while scrolling on https://diffshub.com would love to know more context (device/diff link/etc) because that is very much NOT our experience.

Even the linked ghostty PR on your home shows this - this is Firefox Android on a Nokia XR21 / TA-1486.

It's not unuseable, but it definitely feels like 'js hacking my scrolling' and not a native surface flinging around.

The experience is actually worse with smaller movements, i guess because my brain is more conscious when breaking the 'finger physically moving the text' illusion.

I don't mean to be dismissive - you're working on a really hard problem, and you're clearly approaching it with a mindset of perfection. I'm posting because I know you're probably able to solve this too :)

Edit: as a point of (unfair) comparison, the codemirror Huge File demo works fine: https://codemirror.net/examples/million/ It does suffer from the occasional partial paint when quickly coasting, but I'm not bothered by this at all, it's far less intrusive than dropping frames / stuttering / etc.

Maybe i need to buy one of these devices to test.

Just to be clear tho, we don't actually scroll jack, native scrolling works as it should and content should move with normal gpu composited scroll. That said, it's possible that loading that much data into memory may be causing causing knock on effects somehow that are just slowing everything down.

Naw, the truth is I'm not really smart or intelligent enough to build a semantic diff system. For that you'll need to wait on a post from one of our smarter devs, this was a post about rendering diffs in a browser.

Yes and no. It would help to improve things a bit when it comes the measure/reconciliation phase (unclear to say how much). However we've already done a pretty good job around batching writes vs reads.

However passing a million lines of code through pretext is unlikely to be very efficient, so a lot of the work around estimation is still very important.

That said, while I don't want to make pretext a direct dependency of the library, there's a good chance I'll explore the possibility of allowing devs to pass it in as an additional argument perhaps improve performance a bit.

It should also be noted that we have a full API to support things like line annotations (comments, etc) that are entirely controlled by the user, so there's always a bit of a dynamic aspect there that would come into play

I think it's amazing how deep you can go in something as simple as rendering diffs, and I'm really grateful you shared that writeup (in fact I've been following you loosely since the Kiip days as a then aspiring designer+developer type).

I've always been curious how products like ag-grid are able to allow you to lazy-load 10,000,000+ rows in a table without the blanking you described, and I imagine this type of method describes how it can be done.

Performance and optimization is one of many pieces, but yes, it's a meme to render 500k lines.

That said though, and maybe I didn't say it well in the post, the more performant and optimized your tool is, the less burden you put on developers and users.

Sure you won't review 100k lines, but maybe the diff includes a ton of testing snapshots, or maybe it's a long running feature branch and you need to just quickly jump in and look at a specific change from a specific file. The less the developer or the user needs to think about `how` to render the diff or `how to navigate the diff`, the better we did our job.