Virtual DOM in Elm

Having done some benchmarks with TodoMVC before, I knew something was off about these results.<p>They play to the strengths of the virtual dom approach by manipulating the benchmark via dom instead of what ever interface was implemented within each TodoMVC implementation.<p>So I forked the benchmark and changed both the Backbone and Mercury implementations to work through their respective apis.<p>Here it is: <a href="https://github.com/smelnikov/todomvc-perf-comparison" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;smelnikov&#x2F;todomvc-perf-comparison</a><p>as you can see the giant gap between Backbone and mercury is now gone while both tests perform the exact same tasks. (feel free to step through it in the debugger to see for yourself)<p>Here&#x27;s my commit log: <a href="https://github.com/smelnikov/todomvc-perf-comparison/commit/7e1a5f8f4150a6436b9eeba233102b64a2bd5a78" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;smelnikov&#x2F;todomvc-perf-comparison&#x2F;commit&#x2F;...</a><p>Note: I&#x27;ve added a new method to the Backbone implementation for toggling completed state as the old one was horribly in-efficient. This is not something inherit in Backbone but rather is specific to this TodoMVC implementation. See my comments in the commit log.<p>Note 2: Exoskeleton, which is basically backbone without the jQuery dependency is roughly 2-3x faster than vanilla backbone, I&#x27;m going to predict that it will actually be significantly faster than mercury.<p>Note 3: I think the virtual dom is great and seemingly has many benefits but I feel as though the speed benefit has been greatly exaggerated.

There&#x27;s another advantage to virtual DOM: you can hot-swap code while developing and have React run its diff algorithm without reloading the page. If your component has no (or little) side-effects, it means you get live reload as you edit for free. This is impossible with Backbone&#x2F;jQuery soup of a view.<p>See my proof of concept video: <a href="https://vimeo.com/100010922" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;100010922</a><p>And actually runnable example that you can edit without refresh: <a href="https://github.com/gaearon/react-hot-loader" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gaearon&#x2F;react-hot-loader</a><p>I plan to write a blog post explaining how to integrate it into React project soon.

This technique may be the most revolutionary thing in web development in the last several years, IMHO. I&#x27;ve been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it&#x27;s not only far better performant, but a way better abstraction for dealing with UIs, is crazy.

My first thought when looking at the benchmarks is that I find it strange that Backbone is faster than React. Not that I imagine Backbone to be slow, particularly, just that this article is about one of React&#x27;s key features - the virtual DOM - and that&#x27;s something which Backbone doesn&#x27;t have. I&#x27;d expect to see React up there with Om, Mercury &amp; Elm.<p>I&#x27;ve just had a look at the code and React is using a localstorage backend, while Backbone is using its models + collections with a localstorage extension... so I&#x27;d expect there to at least be some overhead there, but apparently not.<p>Does anyone have any quick thoughts on what might be happening here? I can&#x27;t shake the feeling that these benchmarks might not be terribly useful.

Why so many strings and so few types, especially for somethings like Elm?<p>The same in PureScript would be<p>profile user = mkUI spec do div [ className &quot;profile&quot; ] [ img [ src user.picture ] , span [ text user.name ] ]<p>See, types everywhere. <a href="https://github.com/purescript-contrib/purescript-react/blob/master/example/tutorial/tutorial.purs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;purescript-contrib&#x2F;purescript-react&#x2F;blob&#x2F;...</a>

Virtual DOM is fast, but it&#x27;s not the only way to provide free and fast DOM updates. The author removed the Vue.js implementation from the benchmark, which does not use Virtual DOM but is as fast or even faster than Mercury and Elm.<p>Disclaimer: I&#x27;m the author of Vue.js. The benchmark is a fork of a fork of the Vue.js perf benchmark (<a href="http://vuejs.org/perf/" rel="nofollow">http:&#x2F;&#x2F;vuejs.org&#x2F;perf&#x2F;</a>).

As a startup who&#x27;s built all of its UI on AngularJS, does introducing React&#x2F;Om into the stack make sense? We have a B2B product where the users deal with a lot of CRUD forms and dashboards.<p>React looks interesting, but only if it gives significant advantages (time-to-market, maintainability, etc) vis-a-vis AngularJS in managing a large code-base.<p>Any first hand reviews?

All of the empty brackets to describe the virtual DOM looks bad to me. I&#x27;m curious if this is regarded as a language smell.

Elm looks extremely promising to me. However, I tried the Elm&#x27;s implementation of TodoMVC here: <a href="http://evancz.github.io/TodoFRP/" rel="nofollow">http:&#x2F;&#x2F;evancz.github.io&#x2F;TodoFRP&#x2F;</a> and got an unusable list of strings with basically none of the features seen in other prototypes. Is it the one used in these benchmarks? What results would we see in an identical test?<p>Update: the benchmark uses a correct implementation available here: <a href="https://github.com/evancz/todomvc-perf-comparison/tree/master/todomvc/elm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;evancz&#x2F;todomvc-perf-comparison&#x2F;tree&#x2F;maste...</a> so it was a false alarm on my part. Tried it out at <a href="https://rawgit.com/evancz/todomvc-perf-comparison/master/todomvc/elm/index.html" rel="nofollow">https:&#x2F;&#x2F;rawgit.com&#x2F;evancz&#x2F;todomvc-perf-comparison&#x2F;master&#x2F;tod...</a>

I&#x27;ve never heard about mercury before! Great to see more virtual DOM development.<p>I hope the new framework gets animation right, I&#x27;d love to see it as flexible as in D3, in my opinion this is something currently React currently lacks (the transitions are there but they are too simplistic to cover complex web app cases).

Anyone know of a Haskell or proper Haskell subset that can do something similar (hopefully batteries included)?

You can run the tests by yourself here: <a href="http://evancz.github.io/todomvc-perf-comparison/" rel="nofollow">http:&#x2F;&#x2F;evancz.github.io&#x2F;todomvc-perf-comparison&#x2F;</a>

I&#x27;ve been thinking why there&#x27;s no virtual dom implementation other than react. Glad to see there&#x27;s finally some out there.

Elm seems Incredibly fast. By using requestAnimationFrame like described in the article I managed to bring my own library to satisfying performances <a href="https://github.com/evancz/todomvc-perf-comparison/pull/1" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;evancz&#x2F;todomvc-perf-comparison&#x2F;pull&#x2F;1</a>

What could possibly be done in the React.js version to make its performance closer to Mercury&#x2F;Elm? I notice some &#x27;shouldComponentUpdate&#x27; methods are already overwritten.<p>Or is this the limit of an overly mutable language like js?

Anybody have any good reviews on elm?