3

In the front end web development many frameworks favor virtual DOM solutions (like virtual-dom from React https://www.npmjs.com/package/virtual-dom). Usually the design reasons cited are avoid the problem of having DOM manipulation as the bottleneck of front end rendering.

  • Why DOM manipulation is slow in current browsers, so that virtual DOM solutions can outperform it?

  • What optimizations browsers themselves could do (are doing) to remove this bottleneck? Could browsers themselves are not developing more batch-like DOM APIs?

As a pointer, I feel it might be something to do with the context switch when the run-time needs to leap from JIT'ed JavaScript to native DOM manipulation code, but I have never found a definitive answer on this.

Mikko Ohtamaa
  • 82,057
  • 50
  • 264
  • 435
  • The DOM is not slow, that seems to be a modern myth. The "virtual DOM" employed by React a) is more declarative b) copes better with complete re-recreation of components happening all the time. – Bergi Jul 12 '16 at 15:29
  • 2
    In short: the DOM API does not support batching. Everything runs in immediate mode and that's slow. – ssube Jul 12 '16 at 15:29
  • 3
    @ssube: What exactly is "everything"? Reflowing and repainting is certainly batched in native DOM. – Bergi Jul 12 '16 at 15:30
  • @Bergi the actual calls. It's the same problem the first few versions of OpenGL had, where the calls were all made in immediate mode and the driver(/browser) *could* batch things, sometimes, but there was a lot of overhead. – ssube Jul 12 '16 at 15:32
  • @ssube My question is *what* makes that overhead? – Mikko Ohtamaa Jul 12 '16 at 15:32
  • 2
    http://stackoverflow.com/q/21109361/315168 – Mikko Ohtamaa Jul 12 '16 at 15:54
  • 1
    The conjecture from @ssube is likely the major culprit. But why? My conjecture is (a) context switching costs as you say, (b) the need to make each call atomic and result in a valid and consistent DOM state (e.g. connecting child/parent pointers etc) (c) thread synchronization that likely occurs when you write to the DOM. By operating in batch/bulk, you effect more changes per costs associated with context switching, state consistency, and thread synchronization. – Brandon Jul 12 '16 at 16:17

1 Answers1

-3

Everytime you manipulate Dom repainting and reflowing occurs.

A repaint occurs when changes are made to an elements skin that changes visibility, but do not affect its layout. Examples of this include outline, visibility, or background color.

Virtual Dom makes sure you are always updating the Dom minimalistically.

In frameworks like backbone or building a site with jquery ,you simply insert html to update dom whereas react diffs the previous html and only updates the relevant html.

Virtual Dom is just a patch and a patch is better than updating a major chunk of your page.

Piyush.kapoor
  • 6,715
  • 1
  • 21
  • 21
  • 2
    Thank you. So my question is what prevents browsers themselves to have an API that you could update major chunk of the page without triggering extraneous flows? As this seems to be a major concern for modern front end development. – Mikko Ohtamaa Jul 12 '16 at 15:35
  • 6
    This answer is wrong. [It does not occur *every* single time](http://stackoverflow.com/q/510213/1048572). – Bergi Jul 12 '16 at 15:46
  • Native DOM is not slow, all libraries prior to React (Virtual DOM) was having implementations which was causing heavy DOM repaints. Following articles explains it in better way - https://auth0.com/blog/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ - http://teropa.info/blog/2015/03/02/change-and-its-detection-in-javascript-frameworks.html – Sandip Nirmal Mar 28 '17 at 13:44