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

51–60 of 73 posts

Re: On Rendering Diffs

#51

Post by shay_ker »

gloria_mundi wrote: post #42

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

hmm it does seem like a good point that browsers should be able to do this natively. the DOM already holds the content, and browsers manage what's rendered in the viewport.

Re: On Rendering Diffs

#52

Post by lxe »

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.

Re: On Rendering Diffs

#53

Post by _ZeD_ »

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

Re: On Rendering Diffs

#54

Post by v3gas »

_ZeD_ wrote: post #53

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

Can you give an example of why you need that? Genuinely curious

Re: On Rendering Diffs

#55

Post by charcircuit »

mrkcsc wrote: post #50
charcircuit wrote: post #48

Earlier quoted context omitted.

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.

OK but thats simply doesn't perform. 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.

I just tested it now and Chrome does not freeze when opening up a page with a million lines of code. I repeated a file from the Linux kernel 600 times to reach over 1.1 million lines and I put each line in a div so I could alternate red and green background colors.

>you can fix things within your control

Blink is open source. Improving the browser is fully within your control and since browser automatically updates these optimizations will make it to your end users in a relatively short amount of time.

Re: On Rendering Diffs

#56

Post by chrismorgan »

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';

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.

Re: On Rendering Diffs

#57

Post by amadeus »

charcircuit wrote: post #55
mrkcsc wrote: post #50

Earlier quoted context omitted.

OK but thats simply doesn't perform. 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.

I just tested it now and Chrome does not freeze when opening up a page with a million lines of code. I repeated a file from the Linux kernel 600 times to reach over 1.1 million lines and I put each line in a div so I could alternate red and green background colors. >you can fix things within your control Blink is open source. Improving the browser is fully within your control and since browser automatically updates t…

Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use.

Also this works in all browsers, fixing blink doesn’t help move the web forward.

Re: On Rendering Diffs

#58

Post by jiehong »

v3gas wrote: post #54
_ZeD_ wrote: post #53

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

Can you give an example of why you need that? Genuinely curious

git merge conflicts?

Re: On Rendering Diffs

#59

Post by charcircuit »

amadeus wrote: post #57
charcircuit wrote: post #55

Earlier quoted context omitted.

I just tested it now and Chrome does not freeze when opening up a page with a million lines of code. I repeated a file from the Linux kernel 600 times to reach over 1.1 million lines and I put each line in a div so I could alternate red and green background colors. >you can fix things within your control Blink is open source. Improving the browser is fully within your control and since browser automatically updates t…

Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use. Also this works in all browsers, fixing blink doesn’t help move the web forward.

I agree. I'm tired of these sites with glitchy scrolling and broken search due to trying to reimplement the browser in javascript.

>fixing blink doesn’t help move the web forward.

Historically making one browser engine faster encourages other engines to also be made faster. And realistically Blink has the majority of the browser market share, so it is the most important one to optimize for. Trying to move the web forward shouldn't be the primary goal. The primary goal should be making a good experience for the user. Niche engines like Firefox's just aren't worth caring about due to its low market share.

Re: On Rendering Diffs

#60

Post by amadeus »

charcircuit wrote: post #59
amadeus wrote: post #57

Earlier quoted context omitted.

Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use. Also this works in all browsers, fixing blink doesn’t help move the web forward.

I agree. I'm tired of these sites with glitchy scrolling and broken search due to trying to reimplement the browser in javascript. >fixing blink doesn’t help move the web forward. Historically making one browser engine faster encourages other engines to also be made faster. And realistically Blink has the majority of the browser market share, so it is the most important one to optimize for. Trying to move the web for…

Glad we solved glitchy scrolling for now (the title of this blog post was “on rendering diffs”, not “searching diffs”). Browser search on a 36 million line diff would not by great, but it’s something we hope to have a solution for. One step at a time.
Post reply on HN