3 ms·

A few seconds of googling turns up these relevant articles on how browsers paint via GPU (which date back many years): - https://www.chromium.org/developers/de

A few seconds of googling turns up these relevant articles on how browsers paint via GPU (which date back many years): - https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome https://www.chromium.org/developers/design-documents/gpu-acc... - https://www.urbaninsight.com/article/improving-html5-app-performance-gpu-accelerated-css-transitions https://www.urbaninsight.com/article/improving-html5-app-per... - https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... and also how they handle painting and redrawing in general: - https://www.phpied.com/rendering-repaint-reflowrelayout-restyle/ https://www.phpied.com/rendering-repaint-reflowrelayout-rest... - https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ https://www.html5rocks.com/en/tutorials/internals/howbrowser... - https://james-priest.github.io/udacity-nanodegree-mws/course-notes/browser-rendering-optimization.html https://james-priest.github.io/udacity-nanodegree-mws/course... So no, browsers don't "recompute the entire window". They know what DOM nodes have been mutated, and are able to fairly efficiently redraw just those pieces of the UI that have changed. I haven't watched the video yet, but React's approach to defining UI structure and updates is considerably different than your typical desktop UI toolkit (ie, Swing, Windows Forms, MFC, Qt, etc). With those classical frameworks, you generally have a bunch of object-oriented class inheritance hierarchies and manually instantiated child widgets with specific parameters (`button.setWidth(80)`, `button.setPosition(20, 40)`, etc), then add a lot of event listeners to manually modify both the data and the UI. As I previously mentioned, React expects to work with a "retained mode" environment, such as the DOM, where previously-set UI layouts persist until such time as they are modified. React is explicitly based on determining what the current UI _ought_ too look like based on your current state. The problem that frequently plagued jQuery-type UIs is figuring out how to transition the UI contents from where it was previously to where it needs to be now, taking into account all the possible permutations of what could be shown on screen. With React, you tell it what UI output you want at any point in time based on your current state, and it takes care of figuring out what relatively minimal set of changes actually need to be applied.

PaulDavisThe1st 6y ago
Thanks for the links. I'll have to hunt around a bit harder, because it seems that in general, the people who talk in the most detail about browser rendering don't seem to understand the rendering processes in non-browser apps, and vice versa. For example, all of the discussions of GPU usage that you linked to all seem to skip over the fact that (most) native desktop apps do the same thing implicitly c/o the toolkit they're using. If your ListView widget is ultimately drawn using Vulkan or Metal etc., then the exact same set of abstraction processes and delivery to the GPU are going in a a native toolkit app as the browser (which is not suprising, really). AFAICT, React has no access to the browser render tree, and it can only control the DOM. As such, it is really positioned at a very different level in the "drawing stack" than, say, Qt. At the same time, as you point out, it also isn't particularly close to the widget layout models of "classical frameworks" (even constraint-based versions as have become more common in recent years), because it deliberately tries to prevent you from having too much direct control over the current DOM - that's supposed to be driven by the state. I wish there was a more fruitful meeting place where the experiences of 30+ years of "classical frameworks" could shape and in turn be shaped by the decade plus of "web frameworks". I think that the former has a lot offer the latter and the latter has many ideas and insights that could probably improve the former.

PaulDavisThe1st 6y ago

Thanks for the links. I'll have to hunt around a bit harder, because it seems that in general, the people who talk in the most detail about browser rendering don't seem to understand the rendering processes in non-browser apps, and vice versa. For example, all of the discussions of GPU usage that you linked to all seem to skip over the fact that (most) native desktop apps do the same thing implicitly c/o the toolkit they're using. If your ListView widget is ultimately drawn using Vulkan or Metal etc., then the exact same set of abstraction processes and delivery to the GPU are going in a a native toolkit app as the browser (which is not suprising, really). AFAICT, React has no access to the browser render tree, and it can only control the DOM. As such, it is really positioned at a very different level in the "drawing stack" than, say, Qt. At the same time, as you point out, it also isn't particularly close to the widget layout models of "classical frameworks" (even constraint-based versions as have become more common in recent years), because it deliberately tries to prevent you from having too much direct control over the current DOM - that's supposed to be driven by the state. I wish there was a more fruitful meeting place where the experiences of 30+ years of "classical frameworks" could shape and in turn be shaped by the decade plus of "web frameworks". I think that the former has a lot offer the latter and the latter has many ideas and insights that could probably improve the former.