Yes, but the problem is that you can have slower performance during loading, or you can have slower performance <i>overall</i>, and this is all down to the fact that the DOM does not have a native way of <i>explicitly</i> batching updates, and doing things like touching offset* properties can trigger layouts&#x2F;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&#x27;t use ReactJS, so my bad if this isn&#x27;t correct...).<p>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 <i>have</i> 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.<p>What the DOM really needs, but probably won&#x27;t get because there could be some serious side-effects from bad coding, is a set of simple reference-counted beginUpdate&#x2F;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.<p>I&#x27;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...