Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Performance relating to morphdom vs virtual dom #53

Open
trusktr opened this issue Oct 18, 2016 · 2 comments
Open

Discussion: Performance relating to morphdom vs virtual dom #53

trusktr opened this issue Oct 18, 2016 · 2 comments

Comments

@trusktr
Copy link

trusktr commented Oct 18, 2016

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)
@trusktr trusktr changed the title Performance. Discussion: Performance relating to morphdom vs virtual dom Oct 18, 2016
@shama
Copy link
Collaborator

shama commented Oct 18, 2016

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
Copy link
Contributor

timwis commented Oct 18, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants