5 ms·
For those who are a little unclear on what this is for, there are typically several layers of rendering at play in a modern web app: 1) Re-rendering of virtual
by _bxg1 7y ago
For those who are a little unclear on what this is for, there are typically several layers of rendering at play in a modern web app:
1) Re-rendering of virtual DOM content
2) Mutating the real DOM to match that new virtual DOM
3) The browser actually drawing the new state of the DOM/styles
#1 is your JS code. #2 is covered opaquely by React and peers. #3 is traditionally covered opaquely by the web browser.
This API is a way of giving hints to #3 when that becomes your bottleneck (which is really quite rare, but when it happens, it's extremely nice to have a recourse). If you're experiencing "jank" and are unsure whether this will help, profile your app in Chrome and look for the purple "Reflow" bars in the flame chart. If your chart is mostly orange, your JavaScript is still your bottleneck.
This API is analogous to the compiler hints (assertions, etc.) you can add in certain native languages which allow the compiler to make certain assumptions and therefore optimize more aggressively, where it otherwise might have had to play it safe to ensure correctness.
- kevingadd 7y agoOne other detail to keep in mind is that #3 can only happen once the browser has done DOM layout, and layout can be extremely expensive these days if you have many elements and remotely complex CSS styles. The guarantees provided by contain also make layout faster. One common source of performance issues is that certain JS DOM operations implicitly force the browser to do new layout, so you can end up having to wait for it.
- _bxg1 7y agoI wouldn't say "common". If you avoid "DOM thrashing" (where your code repeatedly mutates the DOM and then measures it and then mutates and then measures), the browser is pretty good at batching these computations and the vast majority of projects will never run into this as a problem. And thrashing is something you should solve by improving your JS, not mitigate with this API.
- The_rationalist 7y agonit: I've never understood why people use the term re-rendering for vdom recomputations. I'm not a native english speaker but as I understand it, rendering means <calculating and/or firing> pixels at the screen. So this term should only be used for step 3) For vdom the term used should simply be re-computing or re-calculating or updating or diffing.
- dwb 7y agoYes and no. "Rendering" in computing has historically mostly meant what you say, but it is defined much more broadly in the dictionary. There's clearly no pressing need to distinguish the pixely variety from virtual DOM calculation with the term (otherwise it wouldn't have caught on), and it works by analogy, so I think it's fine. There's no "should" with language unless people can't understand you.
- The_rationalist 7y agoThere's clearly no pressing need to distinguish the pixely variety from virtual DOM calculation with the term (otherwise it wouldn't have caught on) There is a need: in order to maximise performance, we often talk about avoiding needless vdom recomputations and also about avoiding the browser to recalc the layout aka rerender. If I say in a commit "avoid needless re-rendering of CardList when a Card is added" You cannot understand the nature of the performance issue if you use both re-rendering for vdom and layout. Indeed language evolve to a local minima of being good enough to understand each other good enougthly in most cases. I would have hoped language evolution to improve over time but the world is not ready for creating an institution that would allow that. In the meantime, I and others that understand that maximising semantical understanding matter, will keep voicing.
- _bxg1 7y agoMainly because the React method that gets called is literally "render()". Also, "render" is a more abstract word than that, and can really apply to anything being derived from something else: https://en.m.wikipedia.org/wiki/Rendering_(animal_products)#Rendering_processes_for_edible_products https://en.m.wikipedia.org/wiki/Rendering_(animal_products)#... That said, I can see how the multiple adjacent uses of the term might get confusing
- austincheney 7y ago> 1) Re-rendering of virtual DOM content (#1 is your JS code.) Virtual DOM isn't even a real thing. Its some fiction from React. It is really unfortunate to see the standard layer bloated to compensate for the shortcomings of some framework. None of the benefits provided by this concept seem necessary, as in these same capabilities and performance solutions were already there by other means.
- tyingq 7y agoReact's docs seem honest about "virtual dom" just being a copy of the dom in memory.
- _bxg1 7y ago> It is really unfortunate to see the standard layer bloated to compensate for the shortcomings of some framework. That's not remotely what's happening. You could have the same issues with (and use this API on) a jQuery-mutated DOM.
- austincheney 7y agojQuery is also not the DOM.
- nicoburns 7y agoThe point is that this attempts to fix performance issues with the DOM itself. These are present regardless of whether you are using abstractions on top of the DOM or not. And in fact, the existence of these perf problems with the DOM is one of the reasons for the creation of vdom layers.
- austincheney 7y agoWhat performance issues? The DOM executes in the browser at near assembly speed. Example: https://news.ycombinator.com/item?id=22321333 https://news.ycombinator.com/item?id=22321333