41–50 of 73 posts
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.
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)?
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,…
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.
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…
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 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.
How would you handle it?
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.
> I feel like virtualization is not the right way to handle things. How would you handle it?
Earlier quoted context omitted.
> I feel like virtualization is not the right way to handle things. How would you handle it?
Keep things as simple as possible and put the whole thing in the DOM. Then if there are performance problems address the scaling problems themselves instead of trying to avoid scaling. For example things like only rendering what is visible should be handled by the browser and not by messing with the DOM. The DOM is not synchronized with the browser's renderer so it will always end up hacky.
You can't say "only rendering what is visible should be handled by the browser" and call that a solution unless you have a magic wand to make Chrome/other browsers do this.
The browser doesn't do this, and so you can either do what you say and have your browser freeze when you load up a million line diff, or you can fix things within your control which is what the author is doing.