- Benchmarks are only for Safari and without good documentation for how they
were performed. Measurements are only in the 100ths of seconds where these
measurements should have much more granularity.
- The TodoMVC (arguably the most real-world) benchmark is nearly 50% slower
than virtual-DOM.
- virtual-DOM is fairly mature at this point where as MorphDOM looks very
young.
- virtual DOM implementations allow you to do things like React Native
Author of morphdom here. I don't necessarily disagree with anything you said. However, morphdom was designed to be fast enough in situations where you can't or don't want to introduce a virtual DOM. What matters more than a micro benchmark is the performance in a real application and paired with a real UI framework. Would I use morphdom in situations that required rerendering 1000 nodes every 10ms? Probably not. However, it will perform very well in almost most of the typical use cases. There was a lengthy discussion on performance in the following Github issue where I go into more detail on my thoughts: https://github.com/patrick-steele-idem/morphdom/issues/2
> virtual-DOM is fairly mature at this point where as MorphDOM looks very young.
morphdom is small and focused (about 220 lines of code). It either works or it doesn't and I have a decent amount of test cases to hopefully prove that it works (not to say that it is bug free... the DOM has lots of edge cases in some web browsers).
- virtual DOM implementations allow you to do things like React Native
This was built for the real DOM. While there can be value in abstractions, this was designed for a web browser.
Noted. Meanwhile, this is 12.3kB (uncompressed) while React's core (minus addons or anything) is 121.7kB. For something as young as this, and to do fairly well in a number of benchmarks compared to the highly engineered piece of work that is React is pretty great.
This library can only get better. It's great to see someone trying to make a more lightweight React.
Also, you can see exactly how the benchmarks are run through the /test folder. My test using PhantomJS gave me the same results as the recorded statistics against Safari. And because it uses the browser's built in DOM toolkit rather than a virtual one, (in theory) it should become faster whenever browser DOMs become faster.
> it should become faster whenever browser DOMs become faster
The killer feature of React is that it made it possible to efficiently rerender the entire UI and for developers to not have to write code to manually manipulate the DOM. I hope browser vendors take note of this and do more to support this use case. Ideally, morphdom should not even exist and we could instead have the browser natively do the job of diffing/patching the DOM. Admittedly, there would have to be a lot of details to work out, but React, virtual-dom and morphdom are working in the right direction. Behind the scenes, the implementation might change and any good UI framework should make this a non-breaking change.
Allow me to introduce you to Mithril (http://mithril.js.org/), the 18kB (uncompressed) virtual-dom implementation that beats React in many benchmarks.
> And because it uses the browser's built in DOM toolkit rather than a virtual one, (in theory) it should become faster whenever browser DOMs become faster.
...as will all virtual-dom implementations get faster as JS becomes faster. I would argue that there is more attention paid to JS-speed than DOM-speed because there is a server-side (among other things).
Here's the notable differences based on my understanding after looking over the docs and the source code:
- morphdom does diffing between two real DOM trees while incremental-dom does diffing between virtual DOM nodes and real DOM nodes
- incremental-dom is only meant to be used with templates that compile to use incremental-dom (won't work with templates that render to HTML strings)
- morphdom can be used with any templating engine that produces an HTML string (or real DOM nodes)
- With additional improvements, morphdom could be used to do diffing between a real DOM tree and a virtual DOM tree as long as the virtual DOM nodes are upgraded to real DOM nodes if they need to be added to the final real DOM. In addition, the virtual DOM nodes would need to have an API that overlaps with the API of real DOM nodes.
Also, it appears that incremental-dom doesn't reuse DOM nodes that move to a new parent, but I could be mistaken. Hopefully someone more familiar with incremental-dom will chime in.
The virtual dom solutions can run outside, without a full DOM implementation, which are very slow and resource intensive on a server. Which is needed for client+server-side rendering options.
You don't need a virtual DOM or real DOM on the server to render HTML. The fastest way to render pages on the server is to compile templates into JavaScript programs that produce an HTML string (not virutal DOM nodes and definitely not real DOM nodes) and you can use almost any HTML templating engine to do client+server side rendering. morphdom is only meant for use in the browser when you need to update the DOM based on new HTML/DOM nodes.
True... but React offers a lot in terms of client-side components, and being able to re-use components outweighs having to use a lesser templating system and/or having to manage two rendering paths for each component. Beyond that, virtual DOM nodes aren't too different from an abstraction of rendering against a compiled template.
For the record, I got an email from Hacker News asking me to repost it since they thought it was a good story and it did not get many views. It's not wise to post something to Hacker News late on a Friday :)
I refrained from providing commentary on whether or not posting it a second time is "good" or "bad". While small, there was commentary on the previous link, and that commentary might be valuable to people. I personally think that Hacker News should have an integrated feature that shows "previous discussions" of every posted link. FWIW, reddit has that feature, and it is extremely valuable. (I provide this extra context, as someone down voted my attempt to be useful in addition to you providing a semi-defensive response.)
