4 ms·

I don't have technical references to point to atm, but as far as I know, browsers _do_ go to great lengths to only actually repaint portions of the page that ha

I don't have technical references to point to atm, but as far as I know, browsers _do_ go to great lengths to only actually repaint portions of the page that have changed. There's lots of layer compositing on GPUs, checks to see what DOM nodes were mutated, etc. Nothing framework-specific here at all - this is how all modern browsers are implemented. React in turn does work to let you, the developer, divide your UI code into discrete components that control the layout of some subset of the page, and lets you declare what the UI should look like at any given point in time based on our data. React then tries to minimize the number of DOM updates that have to be modified to make the previous DOM structure look like the structure you said you want now.

PaulDavisThe1st 6y ago
Assuming that you're right about the browser avoiding invalidating windows rects unnecessarily, that still leaves the fundamental problem that DOM elements are not widgets in the way that (say) GtkListView and GtkTextView are. In a desktop GUI toolkit, you can alter one of those entirely independently of the other (and because of the typically non-overlapping assumption of most widget-centric toolkits, only resizing will ever create a dependency between them for the parent window). More technically: if you change the content of a desktop text view widget, then there is more or less a straightforward and simple code path from the widget invalidating its own rect to the native window/graphics system causing a re-render of just that rect. The toolkit really has almost no work to do to make this happen, and neither does the native window/graphics system. But in the browser model, the DOM is an abstract model that may or may not map easily onto window rects. So to decide what will be invalidated in the (native) window, the browser has to essentially recompute the entire window and then decide what to invalidate at the native window/graphics level. Are you sure about layer compositing on GPUs within the browser? My guess is that this is done mostly by the (desktop/native) toolkit used by the browser and is an optional optimization, since the browsers will function normally without a GPU. At some level though, I think you're right and that the video is wrong in some deep way: the way I was first told about React made it sound precisely like "it is designed to work more like a desktop toolkit", and given this, the video misses one of the more fundamental reasons for contemporary web frameworks.
- acemarke 6y ago
  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

Assuming that you're right about the browser avoiding invalidating windows rects unnecessarily, that still leaves the fundamental problem that DOM elements are not widgets in the way that (say) GtkListView and GtkTextView are. In a desktop GUI toolkit, you can alter one of those entirely independently of the other (and because of the typically non-overlapping assumption of most widget-centric toolkits, only resizing will ever create a dependency between them for the parent window). More technically: if you change the content of a desktop text view widget, then there is more or less a straightforward and simple code path from the widget invalidating its own rect to the native window/graphics system causing a re-render of just that rect. The toolkit really has almost no work to do to make this happen, and neither does the native window/graphics system. But in the browser model, the DOM is an abstract model that may or may not map easily onto window rects. So to decide what will be invalidated in the (native) window, the browser has to essentially recompute the entire window and then decide what to invalidate at the native window/graphics level. Are you sure about layer compositing on GPUs within the browser? My guess is that this is done mostly by the (desktop/native) toolkit used by the browser and is an optional optimization, since the browsers will function normally without a GPU. At some level though, I think you're right and that the video is wrong in some deep way: the way I was first told about React made it sound precisely like "it is designed to work more like a desktop toolkit", and given this, the video misses one of the more fundamental reasons for contemporary web frameworks.

acemarke 6y ago
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.