4 ms·

virtual-dom may be faster than React.js in benchmarks. However the React example [1] that the author rebuilt with MVI [2] is much slower with many elements. Wha

• nthtran 12y ago
  The author didn't include an optimisation that the React example has. In React you can use the PureRenderMixin [0] to avoid re-rendering subtrees if the arguments passed in are the same. In virtual-dom there's something similar called Thunk [1]. I did a partial implementation of the demo here [2] using Thunk. You can see that it performs much better than React for many thousand items. Adding items is also faster using virtual-dom. [0] http://facebook.github.io/react/docs/pure-render-mixin.html http://facebook.github.io/react/docs/pure-render-mixin.html [1] https://github.com/Raynos/vdom-thunk https://github.com/Raynos/vdom-thunk [2] http://nthtran.github.io/mercury-demo6-v2/ http://nthtran.github.io/mercury-demo6-v2/
  • glenjamin 12y ago
    From a quick look at the demo, the React version also doesn't use PureRenderMixin. The optimisation that the React version has that is not applied in the virtual-dom version is list keys. http://facebook.github.io/react/docs/reconciliation.html#keys http://facebook.github.io/react/docs/reconciliation.html#key... I don't know if virtual-dom provides an equivalent feature, but I imagine it would be straightforward to add if not.
    • nthtran 12y ago
      The React demo does use PureRenderMixin [0]. And virtual-dom also supports keys. [0] https://github.com/BinaryMuse/react-primer/blob/gh-pages/demo6/item.jsx#L44 https://github.com/BinaryMuse/react-primer/blob/gh-pages/dem...
      • glenjamin 12y ago
        Ah yes, I only read the top file, didn't realise the demo was split into multiple components. Do you have a link to the source for the virtual-dom version?
  • hackerboos 12y ago
    Thank you for commenting. Although I like the new pattern the author presented I almost dismissed it because the performance was significantly worse than the react example.