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