In any case, I think it's cool to use the Virtual DOM when you need, but React and Mithril forcing you to re-render EVERYTHING every time is a bit too heavy-handed.
In any case, I think it's cool to use the Virtual DOM when you need, but React and Mithril forcing you to re-render EVERYTHING every time is a bit too heavy-handed.
All three libraries have similar virtual dom implementations. In all of them, rendering to the DOM itself only happens on nodes that need it, otherwise nodes aren't touched at all. Diffing is what runs on the entire template on every redraw, but all 3 libraries provide APIs to skip diffing of certain areas of the template based on some condition (i.e. React has shoudComponentUpdate, Mithril has subtree directives, Mercury has thunks).
Diffing everything on a redraw might sound expensive, but it's actually a pretty good strategy performance-wise, and more importantly, it makes it easier to reason about and fix performance bottlenecks, compared the alternatives used by older frameworks (dirty checking, observables)
Between Mithril and Mercury, honestly, they are fairly similar in terms of what they offer. Mercury's modularity makes its parts popular among projects that aren't strictly web applications themselves, whereas Mithril has a very strong focus on powering web apps (e.g. docs-are-a-must policy, small footprint and API surface, no build system required, etc)
The topic of my talk and excercises was building & scaling modern web apps. That's we used:
React, Yeoman, Mimosa.io, Swagger, Strongloop, Redhat OpenShift, Microsoft Azure and VisualOps.io to quickly build a build framework, deployment targets and a workflow for a 'large' sample application and develop modules for the web app that consumes other APIs.
We've also used Mimosa.io and Yeoman and have followed the tutorials on their websites and were very pleasantly surprised. Especially the tutorial on Yeoman's site was stellar. I think integrating Mithril with both of these frameworks with one empty and one opiniated boilerplate to quickstart into coding without having to create the js/css/html files by hand would be more practical to follow by total newcomers. It would also fit the keyword "modern" in my talk more than having to do it by hand.
Thank you for taking the time to read this far! You're invited to a cool and chilled beer (or coffe), when you have the pleasure to visit Germany :)
That's why Om is faster than React out of the box even though it's implemented on top of React: it can makes assumptions the generic React can't (namely that all component state is immutable and provided through the component's cursor) and can thus set up a fast and generic `shouldComponentUpdate`.