Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Rendering Diffs

pierre.computer

Post reply on HN
Print view View original

11–20 of 73 posts

Re: On Rendering Diffs

#11

Post by amadeus »

joosters wrote: post #7

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 inv…

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.

Re: On Rendering Diffs

#13

Post by mi_lk »

cipherself wrote: post #3

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

There's always reader mode when an author tries to be cute about their layout

Re: On Rendering Diffs

#14

Post by 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.

Re: On Rendering Diffs

#16

Post by amadeus »

nerdypepper wrote: post #14

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.

Re: On Rendering Diffs

#17

Post by manquer »

joosters wrote: post #7

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 inv…

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

Re: On Rendering Diffs

#20

Post by amadeus »

cvince wrote: post #18

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

Post reply on HN