4 ms·

Yes, but the problem is that you can have slower performance during loading, or you can have slower performance overall, and this is all down to the fact that t

Yes, but the problem is that you can have slower performance during loading, or you can have slower performance overall, and this is all down to the fact that the DOM does not have a native way of explicitly batching updates, and doing things like touching offset* properties can trigger layouts/repaints. ReactJS uses DOM tree diffing and merging, but that can also get you into trouble with the GC (this may be a solved issue, don't use ReactJS, so my bad if this isn't correct...). Our product, Elevate Web Builder, uses an in-memory element representation with a DOM change management architecture that avoids all of these issues. However, because of this design, you have to use our product and our framework in order to benefit from it, because it sits as a virtual layer on top of the DOM. What the DOM really needs, but probably won't get because there could be some serious side-effects from bad coding, is a set of simple reference-counted beginUpdate/endUpdate methods on each DOM element that isolate that portion of the DOM tree from repaints, but not layouts. That way, dimensional information is always immediately available, but painting is always handled as a single last step. I'm meandering here, but the point is that improvements in the DOM management layer of the browsers could drastically cut the necessity of frameworks whose primary purpose is to work around deficiencies in the DOM. Fix the browsers, and you fix the load time. Cutting out the frameworks just ends up trading different kinds of pain...

nostrademons 11y ago
The DOM already does dirty-checking on manipulation. Manipulating the DOM is cheap, it's manipulating the DOM while also getting dimension or style information that's expensive. None of the major frameworks solve this problem. The closest may be React, which strongly discourages you from interacting with real DOM nodes or doing anything stateful, but even then, if you really want to touch that offsetWidth you can trivially destroy React's performance. Maybe the best alternative is just strict coding standards that say "Don't do that!" I'd talked with a few Chrome PMs when I was working on Material Design for Google Search and discussed the possibility of some sort of batching API for layout-causing operations. They weren't against it in principle, but nobody could think of an API that was something we'd actually use as web developers. The problem is that thinking about your app in terms of "This expression causes layout, this expression dirties the DOM" is a big cognitive load, and making those two classes of expressions non-interleavable means you suddenly need to structure your whole app in different ways. There'd also been talk of doing a subset of HTML that includes only the operations that can be done quickly, but to my knowledge, that never went anywhere. You run into problems with the whole huge installed base of the web; if you're going to throw everything out and start from scratch, why not just use a native mobile app, or even raw OpenGL ES commands?
- munro 11y ago
  It's no surprise that mutating data structures is cheap, and React's virtual DOM doesn't aim to solve expensive layout calculation. What virtual DOM does is simplify application development by removing the concept of time, so the programmer doesn't have to think about how to mutate the existing state to get to the new state. It's the cheapness of creating new virtual nodes that's interesting [1], and quickly applying them to the DOM with diffing. [1] https://jsperf.com/virtual-dom-vs-real-dom https://jsperf.com/virtual-dom-vs-real-dom
- TimJYoung 11y ago
  Thanks for the response. "The DOM already does dirty-checking on manipulation. Manipulating the DOM is cheap, it's manipulating the DOM while also getting dimension or style information that's expensive." Yes, absolutely, and I wasn't clear on this point. The catch, however, is that once you start using JS for dynamic rendering of UI elements, as opposed to static HTML, this becomes quite the problem. Simple things like dragging an element around or other types of basic interactivity require knowing where things are in real time. "None of the major frameworks solve this problem. The closest may be React, which strongly discourages you from interacting with real DOM nodes or doing anything stateful, but even then, if you really want to touch that offsetWidth you can trivially destroy React's performance. Maybe the best alternative is just strict coding standards that say "Don't do that!"" The only way I know of around this problem is what we did: maintain a virtual element for each actual DOM element, and have the virtual element act as a gatekeeper to the DOM. Want to read the width ? No problem, here it is as a simple integer property, and the DOM isn't touched. But, as you can imagine, this sends you down the road to hell pretty quickly, and we ended up managing everything manually. We effectively use the browser as a display device. And, of course, the code size is larger than we would like...and we're back to the topic at hand. :-) "I'd talked with a few Chrome PMs when I was working on Material Design for Google Search and discussed the possibility of some sort of batching API for layout-causing operations. They weren't against it in principle, but nobody could think of an API that was something we'd actually use as web developers. The problem is that thinking about your app in terms of "This expression causes layout, this expression dirties the DOM" is a big cognitive load, and making those two classes of expressions non-interleavable means you suddenly need to structure your whole app in different ways." Having come from many years doing desktop development on Windows, I've become accustomed to BeginUpdate/EndUpdate as it's a pretty standard way of batching updates that cause repaints. Of course, Windows also punts on layout, so there's a pretty big difference right there. "There'd also been talk of doing a subset of HTML that includes only the operations that can be done quickly, but to my knowledge, that never went anywhere. You run into problems with the whole huge installed base of the web; if you're going to throw everything out and start from scratch, why not just use a native mobile app, or even raw OpenGL ES commands?" I would say that you're leaving out a whole host of things that make the browser such an attractive host environment for applications, absent automatic layouts. There's the painting capabilities alone. Ever try to deal with transparency in Windows ? It's a nightmare, but in the browser it just works. The DOM element tree model itself is beautiful and a perfectly natural way of visualizing a UI. In general, it's just a more complete environment for the developer, and there's no arcane API to work around: access to the built-in functionality is just an object property away. Then there's the single codebase, easy distribution/installs..... I just think that browser developers need to actively push towards making the UI functionality more generalized and display-oriented, and less specific to its roots of static documents that always require some sort of layout. If a piece of JS code places an absolutely-positioned element somewhere in the browser window, there should be zero penalty for reading its layout information after doing so.

nostrademons 11y ago

The DOM already does dirty-checking on manipulation. Manipulating the DOM is cheap, it's manipulating the DOM while also getting dimension or style information that's expensive. None of the major frameworks solve this problem. The closest may be React, which strongly discourages you from interacting with real DOM nodes or doing anything stateful, but even then, if you really want to touch that offsetWidth you can trivially destroy React's performance. Maybe the best alternative is just strict coding standards that say "Don't do that!" I'd talked with a few Chrome PMs when I was working on Material Design for Google Search and discussed the possibility of some sort of batching API for layout-causing operations. They weren't against it in principle, but nobody could think of an API that was something we'd actually use as web developers. The problem is that thinking about your app in terms of "This expression causes layout, this expression dirties the DOM" is a big cognitive load, and making those two classes of expressions non-interleavable means you suddenly need to structure your whole app in different ways. There'd also been talk of doing a subset of HTML that includes only the operations that can be done quickly, but to my knowledge, that never went anywhere. You run into problems with the whole huge installed base of the web; if you're going to throw everything out and start from scratch, why not just use a native mobile app, or even raw OpenGL ES commands?

munro 11y ago
It's no surprise that mutating data structures is cheap, and React's virtual DOM doesn't aim to solve expensive layout calculation. What virtual DOM does is simplify application development by removing the concept of time, so the programmer doesn't have to think about how to mutate the existing state to get to the new state. It's the cheapness of creating new virtual nodes that's interesting [1], and quickly applying them to the DOM with diffing. [1] https://jsperf.com/virtual-dom-vs-real-dom https://jsperf.com/virtual-dom-vs-real-dom
TimJYoung 11y ago
Thanks for the response. "The DOM already does dirty-checking on manipulation. Manipulating the DOM is cheap, it's manipulating the DOM while also getting dimension or style information that's expensive." Yes, absolutely, and I wasn't clear on this point. The catch, however, is that once you start using JS for dynamic rendering of UI elements, as opposed to static HTML, this becomes quite the problem. Simple things like dragging an element around or other types of basic interactivity require knowing where things are in real time. "None of the major frameworks solve this problem. The closest may be React, which strongly discourages you from interacting with real DOM nodes or doing anything stateful, but even then, if you really want to touch that offsetWidth you can trivially destroy React's performance. Maybe the best alternative is just strict coding standards that say "Don't do that!"" The only way I know of around this problem is what we did: maintain a virtual element for each actual DOM element, and have the virtual element act as a gatekeeper to the DOM. Want to read the width ? No problem, here it is as a simple integer property, and the DOM isn't touched. But, as you can imagine, this sends you down the road to hell pretty quickly, and we ended up managing everything manually. We effectively use the browser as a display device. And, of course, the code size is larger than we would like...and we're back to the topic at hand. :-) "I'd talked with a few Chrome PMs when I was working on Material Design for Google Search and discussed the possibility of some sort of batching API for layout-causing operations. They weren't against it in principle, but nobody could think of an API that was something we'd actually use as web developers. The problem is that thinking about your app in terms of "This expression causes layout, this expression dirties the DOM" is a big cognitive load, and making those two classes of expressions non-interleavable means you suddenly need to structure your whole app in different ways." Having come from many years doing desktop development on Windows, I've become accustomed to BeginUpdate/EndUpdate as it's a pretty standard way of batching updates that cause repaints. Of course, Windows also punts on layout, so there's a pretty big difference right there. "There'd also been talk of doing a subset of HTML that includes only the operations that can be done quickly, but to my knowledge, that never went anywhere. You run into problems with the whole huge installed base of the web; if you're going to throw everything out and start from scratch, why not just use a native mobile app, or even raw OpenGL ES commands?" I would say that you're leaving out a whole host of things that make the browser such an attractive host environment for applications, absent automatic layouts. There's the painting capabilities alone. Ever try to deal with transparency in Windows ? It's a nightmare, but in the browser it just works. The DOM element tree model itself is beautiful and a perfectly natural way of visualizing a UI. In general, it's just a more complete environment for the developer, and there's no arcane API to work around: access to the built-in functionality is just an object property away. Then there's the single codebase, easy distribution/installs..... I just think that browser developers need to actively push towards making the UI functionality more generalized and display-oriented, and less specific to its roots of static documents that always require some sort of layout. If a piece of JS code places an absolutely-positioned element somewhere in the browser window, there should be zero penalty for reading its layout information after doing so.