
Virtual-dom – A Virtual DOM and diffing algorithm - cleverjake
https://github.com/Matt-Esch/virtual-dom
======
arianvanp
To explain why this is nicer than react:

virtual-dom makes zero to non assumptions about your architecture. which I
like. It's just dumbly a diffing algorithm and that's it.

Mercury[0] is a "framework" (A collection of opinionated modules) that builds
on top of this to give a more complete app stack. And it's really fast[1].

Because it's so dead simple and takes so little assumption, it's really easy
to mold to your needs. For example, we've chosen to use it for our Haskell
virtual-dom implementation[2]. Also Elm has chosen to use this library for
their `elm-html` library [3] and PureScript is using it too [4].

So it's also nicer (in my opinion) from a technical perspective. Not just a
licensing perspective.

[0] - [https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)
[1] - [http://elm-lang.org/blog/Blazing-Fast-Html.elm](http://elm-
lang.org/blog/Blazing-Fast-Html.elm) [2] - [https://github.com/ghcjs/ghcjs-
vdom](https://github.com/ghcjs/ghcjs-vdom) [3] -
[https://github.com/evancz/elm-html](https://github.com/evancz/elm-html) [4] -
[https://github.com/purescript-contrib/purescript-virtual-
dom](https://github.com/purescript-contrib/purescript-virtual-dom)

~~~
zkhalique
How about Mithril?

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.

~~~
lhorie
Hi, Mithril author here

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)

~~~
FractalNerve
Hi, I've thought a classroom with master students in computer science Mithril
and we've found that the tutorials on your Homepage aren't easy to follow. A
girl for example wanted to follow the tutorial 1:1 but found herself stuck, we
know that the code at the bottom of the page worked, however I would heartly
support you and your framework more, if there were easier to follow tutorials,
more examples, integrations into build systems 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 :)

------
crncosta
Really nice job, thank you!

React is patented
[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)
which is, IMO, a reason to applaud the rise up of alternatives like this one.

I just hope the author is not infringing React patents in his implementation.

~~~
zkhalique
Well it seems this patent is only there for defensive purposes.

~~~
_delirium
Patent-retaliation clauses are common, but the React one is a bit unusual. The
one in the GPLv3 is typical: if you sue someone who uses gcc (whether it's the
FSF or a third-party user), alleging that they are infringing some of your
patents through their use of gcc, then your license to gcc auto-terminates.
The justification is something like: if you inhibit others' free use of this
software through litigation, then you can't use it freely either (at least,
until the situation is resolved).

The Facebook retaliation clause differs in two respects:

1\. It protects only Facebook, but extends that protection to disputes
unrelated to the software. Your React license is terminated if you ever end up
in patent litigation with Facebook or a subsidiary, regardless of whether it
involves React or not. But it is _not_ terminated if you initiate patent
litigation against third-party React users, unlike the GPLv3 termination. So
it's not strictly a stronger or weaker retaliation clause in this respect, but
I think a "worse" one.

2\. Your React license is terminated if you challenge the validity of any
Facebook patent, even if no lawsuit is involved (e.g. filing an USPTO
challenge), and regardless of whether it involves React. As I read it, this
covers even defensive patent challenges, e.g. if Facebook sues _you_ over a
patent, and you respond by challenging the patent's validity, then your React
license is terminated. This part is particularly nasty imo.

~~~
k__
Can I do this with all my licenses?

I mean, release something as GPL and add "If you sue me in the future, you
license is automatically revoked"

~~~
belorn
If you don't link/include anyone else work, then you can do what you want.

Beyond that, GPL itself does not seem compatible with retaliation clauses
except for patents.

------
jamestomasino
I was watching virtual-dom a while back when the documentation was less clear.
It's an exciting bit of code and I love the way it tries to solve one specific
problem. My challenge to use is require.js, though. Has anyone seen a fork of
this that can implement virtual-dom in vanilla js without that dependency?

~~~
woah
This does not use require.js, it looks like it is using CommonJS. If you
really want to put stuff in the global scope, which is a bad idea and was one
of the biggest shortcomings of js for a long time, maybe this will have some
answers for you: [http://www.mattburkedev.com/export-a-global-to-the-window-
ob...](http://www.mattburkedev.com/export-a-global-to-the-window-object-with-
browserify/)

~~~
jamestomasino
Yeah, I'm not looking to put things in the global scope, but rather to avoid
using AMD module loading. I'm looking for a way to explicitly load the
individual JS files in the proper order. Maintaining namespacing is great.

~~~
woah
Well, the example is CommonJS, not AMD.

------
worldsayshi
Why does the world need this in addition to React? I can _certainly_ feel that
there are reasons but I can't make them concrete off the top of my head.

Edit: Ok, I get it. Now we can add this behavior to arbitrary template engines
or reactive frameworks, like Meteor for example. Thats awesome.

~~~
kpmah
I used it in my side project ([http://sediment.io](http://sediment.io))
because I was using PureScript. It's just a few pure functions that are easy
to bind to. The source code is also a lot easier to read and understand.

~~~
FractalNerve
I start to see .io domains associated with a lot of cool projects, which makes
me ask myself "Where do you buy these io domains?". Is it cheaper than were I
looked? I think it was about >=65Eur/anno

Last time I looked the prices offered for grabbing one I was schocked with
extraordinary high costs for one domain.

------
ilaksh
Maybe someday the real DOM will perform and we won't need this type of thing.

~~~
arianvanp
We're still using the 'real' DOM. Eventually your diffs are just dom
modification instructions. It's just that we generate those instructions
instead of designing them ourselves.

This gives overall good performance without being too imperative. But manual
DOM manipulations, when done well, will still be way faster...

[https://github.com/atom/atom/pull/5624](https://github.com/atom/atom/pull/5624)

------
smrtinsert
hooking this up to clojurescript was also pretty simple thanks to browserify
and their h api. surprised the clj community hasnt explored it mote.

