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.
One of our next big projects is actually to support semantic diffs, which I think will be a lot more applicable to what you're asking for here. Currently diffs just takes a normal git patch file, or generates one from 2 versions of a file.
> rather than the optimizations involved in rendering the text.
Any views they have on this topic is going to come across as quite opinionated given their choices for text rendering for this post and general aesthetics of website.
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.
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.
> 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.
Matters a great deal on desktop too, and laptops for that matter. Even more on platforms like macOS that smooths scrolling by default too, but very noticeable on Windows and various Linux distributions too when native scrolling is janky/choppy, and it frustrates even casual users.
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.
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
For anyone else who's suffering, paste this in the console in devtools:
There's always reader mode when an author tries to be cute about their layout
thank you, how do they live like this.
lmao - thank you!
Aw, Pierre shut down? Is there a write-up on that? (The code review startup idea.)
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.
One of our next big projects is actually to support semantic diffs, which I think will be a lot more applicable to what you're asking for here. Currently diffs just takes a normal git patch file, or generates one from 2 versions of a file.
> rather than the optimizations involved in rendering the text.
Any views they have on this topic is going to come across as quite opinionated given their choices for text rendering for this post and general aesthetics of website.
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.
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.
> 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.
Matters a great deal on desktop too, and laptops for that matter. Even more on platforms like macOS that smooths scrolling by default too, but very noticeable on Windows and various Linux distributions too when native scrolling is janky/choppy, and it frustrates even casual users.
I don’t have much to say except I appreciate the ASCII art.
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.
big fan :)
thank you!
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.
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.
Whatever happened to all the pretext hype? I feel like that would be perfect for rendering huge diffs.
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
Can you select and copy text with pretext?
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.)
Maybe an intended effect, but the header ascii art is suspiciously misaligned... :^)
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?