max-mapper / yo-yo

A tiny library for building modular UI components using DOM diffing and ES6 tagged template literals
1.33k stars 65 forks source link

Discussion: Performance relating to morphdom vs virtual dom #53

Open trusktr opened 7 years ago

trusktr commented 7 years ago

morphdom does not use a virtual DOM, it simply uses the actual DOM.

Is this better? Is it faster than using a virtual dom? I ask, because as far as I know there are costs to instantiating new DOM elements (namely, createdCallback logic when the elements are made with Custom Elements v0, and constructor logic if made with v1 API). From what I know, virtual dom does not instantiate nodes in the virtual tree, and lifecycle methods never run. It's basically just a vanilla JS object structure, then finally, once the difference are ironed out, the needed element are created (and creation logic executed).

Even if using DocumentFragments, I believe that element creation logic is still fired. f.e.

var docFrag = document.createDocumentFragment()
var el = document.createElement('my-element') // runs the element's creation logic
docFrag.appendChild(el)
shama commented 7 years ago

It depends. I wouldn't call one better nor faster than the other. morphdom goes more into depth about actual DOM vs virtual-dom: https://github.com/patrick-steele-idem/morphdom#isnt-the-dom-slow

In practice, so far, I've found performance to be the same. I personally prefer the actual DOM primarily for compatibility reasons.

The ultimate goal is use the native API as a common stable interface and then be able to swap out the rendering engine as needed.

timwis commented 7 years ago

There's also the benefit of the actual DOM being the source of truth: many JS libraries manipulate the DOM themselves. If you use virtual DOM, once those libraries change themselves in the DOM, your virtual DOM is no longer an accurate representation of the DOM.