js-repaint-perfs / dbmonster

Hey @patrick-steele-idem ,

Continuing https://github.com/mathieuancelin/js-repaint-perfs/pull/53 so not to clutter the pull req with OT discussion…

I’m seeing nearly identical performance compared to React

React is quite slow (not sure how much faster v15.0 is). Though you could make the argument that it doesn’t matter from its popularity.

morphdom is tiny (network overhead is often more important… especially in developing countries)

Well, 7.7k (morphdom) [1] vs 10.9k (domvm) [2] or others [3][4][5] is a negligible difference. Even less so after gzip. Developing countries also have slow, shitty phones 😃

While the dbmon benchmark is interesting it is just one use case that is likely not representative of real world usage

True, it’s unrealistic for 100%, 50% and even 20% mutations, but is realistic for 0%-5% mutations.

For example, morphdom provides hooks to avoid diffing/patching DOM subtrees (e.g., onBeforeUpdateEl)

To be fair, many (most?) vdom libs also provide this.

morphdom avoids the memory overhead of maintaining a parallel virtual DOM tree in memory

From the example [6] at least, it looks like it actually creates a much more expensive detached DOM to do the diff, no?

morphdom plays nice with vanilla DOM libraries and web components…morphdom can be used with any library that produces HTML or DOM nodes…[doesn’t rely on non-standardized vtree represenations, treats DOM as the truth]

This is really the main selling point, which is nice.

morphdom will get faster as browsers optimize the DOM

True, perhaps one day: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s

Using morphdom for animation is not recommended (use hardware accelerated CSS transitions or an animation library instead)

I think that using any vdom lib for tick/step based animations is terrible practice.

Disclaimer: I’m the author of domvm [7]…dbmonster [8] (optimized a bit for low mutations yields 145fps @ 1%) or dumb re-diff everything [9] (70fps @ 1%)

[1] https://github.com/patrick-steele-idem/morphdom/blob/master/dist/morphdom-umd.min.js [2] https://gist.github.com/leeoniya/baa5b971f3421d2a628729e456766b8e [3] https://github.com/paldepind/snabbdom [4] https://github.com/joelrich/citojs [5] https://github.com/developit/preact [6] https://github.com/patrick-steele-idem/morphdom#usage [7] https://github.com/leeoniya/domvm [8] http://leeoniya.github.io/domvm/test/bench/dbmonster/ [9] https://github.com/mathieuancelin/js-repaint-perfs/blob/gh-pages/domvm/app.js

[whiteinge]

Short follow-up about the PR. That repo distinguishes between ‘naive’ and ‘optimized’ approaches (the yellow and orange boxes). My addition is obviously not an optimized approach 😉 .

I’m not sure this […] does anything to dispel the belief that the DOM is slow

What has tickled me the most since stumbling on Morphdom is that the DOM performs better than expected. The naive implementation offers middle-of-the-road performance. Most libs on that site are in the mid-twenty to low-thirty redraws/sec range, and only a few hit the very-low or very-high range. The “the DOM is slow” mantra is blindly repeated so often and without qualification in our field it is very refreshing to see that the DOM is Fast Enough ™ for most projects, and for the projects that need more there are always libs like domvm or higher-level additions like Marko. Plus the ~430 SLOC is 😻 .

[patrick-steele-idem]

React is quite slow (not sure how much faster v15.0 is). Though you could make the argument that it doesn’t matter from its popularity.

Very true. While people like to say “React has amazing rendering performance” that is not really what the authors ever claimed. I think it is fair to say that the authors of React have always claimed that it is “good enough”. The authors of React really just wanted to introduce the simplicity of server-side rendering to the browser (i.e., just rerender everything) while maintaining good performance. I think that is a perfectly valid approach.

Well, 7.7k (morphdom) [1] vs 10.9k (domvm) [2] or others [3][4][5] is a negligible difference. Even less so after gzip. Developing countries also have slow, shitty phones 😃

I’m not sure where you are getting your numbers from, but with the online closure compiler: 1.5KB gzipped (3.52KB uncompressed)

True, it’s unrealistic for 100%, 50% and even 20% mutations, but is realistic for 0%-5% mutations.

I’ve rarely seen a web application that needs to constantly rerender the screen unless it is game.

To be fair, many (most?) vdom libs also provide this [lifecycle hooks].

Absolutely. My point is that if you leverage those lifecycle hooks then you will see performance improvements. The dbmon benchmark for morphdom does not leverage any lifecycle hooks…the entire table is blindly rerendered and diffed/patched every frame.

From the example [6] at least, it looks like it actually creates a much more expensive detached DOM to do the diff, no?

My point was that the newly rendered DOM is not persisted in memory after the diffing and patching is completed (only the DOM in the real DOM is persisted… by the browser). With React, there is always a persistent real DOM and a persistent virtual DOM (that is kept around for diffing purposes).

This is really the main selling point, which is nice.

I agree 😃

I think that using any vdom lib for tick/step based animations is terrible practice.

I agree 😃

Disclaimer: I’m the author of domvm [7]…dbmonster [8].

Nice work. I can definitely appreciate the work that goes into maintaining a view library. Personally, I am not a fan of JSONML (or hyperscript for that matter). Disclaimer: I’m the author of marko (an HTML-based templating engine) 😃 On a related note, Marko and Marko Widgets are designed to be super fast:

• Templating Benchmarks
• Marko vs React: Performance Benchmark

From looking at the docs for domvm it is unclear to me how your view library updates the DOM during a redraw. Can you please clarify?

Thanks for the discussion and thanks for helping to move the web forward.