I’m surprised to see such a reaction to a left-aligned content column. I’d have said it was pretty common, though probably not as common as it used to be.
If I were to pick one problem with the presentation, it would rather be the font-size (12px is unequivocally too small), or the use of monospace (simply unsuitable for body text).
And incidentally, HN suffers from two of these three problems.
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.
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.
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" )
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.
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.)
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.
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.
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)?
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?
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.
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
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.
34 comments
[ 2.6 ms ] story [ 46.7 ms ] threadIf I were to pick one problem with the presentation, it would rather be the font-size (12px is unequivocally too small), or the use of monospace (simply unsuitable for body text).
And incidentally, HN suffers from two of these three problems.
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.
(I say this, having done a vibe-port of the code to a browser extension, so the underlying concept works.)
something i'd really want to see from forges is alternate diff techniques: like AST diffing.
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.
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.
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
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?
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?
For a brief hopeful moment, I thought this was the .io kind of sandstorm
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.
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'm still stuck with (k)diff3, and, while they work, I would really like to a more integrate web interface for my projects
Of course. It’s often Safari.