Virtual-dom – A Virtual DOM and diffing algorithm

https://github.com/Matt-Esch/virtual-dom

by cleverjake • 11 years ago

142 39 11 years ago

worldsayshi4• 11 years ago

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.

gondo• 11 years ago

license if not anything else

worldsayshi4• 11 years ago

React is Bsd, this one is also bsd-ish?

edit: why downvotes?

rpwverheij• 11 years ago

exactly.. Just in case you want virtual DOM, but not the rest of React, this comes in very handy

aikah• 11 years ago

Because choice is good. The Javascript world is definitely not a mono culture, get used to it.

worldsayshi4• 11 years ago

I wasn't rejecting it. I was curious.

steveridout• 11 years ago

Size of code could be a good reason:

This appears to be just 43kb: https://github.com/Matt-Esch/virtual-dom/blob/master/dist/vi...

Whereas Facebook react 0.13.1 (without addons) weighs in at 599kb, or 121kb minified.

Note that I know almost nothing about this project. It may do less than React, be slower, etc... But if it does a half decent job with far less code then it's very compelling.

kpmah• 11 years ago

I used it in my side project (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.

FractalNerve2• 11 years ago

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.

crncosta• 11 years ago

Really nice job, thank you!

React is patented 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.

zkhalique2• 11 years ago

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

_delirium2• 11 years ago

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.

BruceM2• 11 years ago

Which React patents exactly?

platform• 11 years ago

This one: " The license granted hereunder will terminate, automatically and without notice, ..... (b) that any right in any patent claim of Facebook is invalid"

Basically if you accept Facebook's license, your right to use Facebook-patented software will terminate, in case you express your view that some other (any) Facebook patent is not valid (say due to prior art).

arianvanp3• 11 years ago

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 [1] - http://elm-lang.org/blog/Blazing-Fast-Html.elm [2] - https://github.com/ghcjs/ghcjs-vdom [3] - https://github.com/evancz/elm-html [4] - https://github.com/purescript-contrib/purescript-virtual-dom

scoot• 11 years ago

Mercury looks like an compelling alternative to React, if only because by comparison React is so unopinionated.

A default stack with the modularity to swap-out as needed should make life easier for someone coming from a Rails Omakasa[1] background, and struggling to choose and learn all the layers needed behind React to make it functional.

[1] http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

zkhalique2• 11 years ago

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.

masklinn• 11 years ago

Not sure about Mithril but React certainly does not force you to re-render everything every time. Bypassing re-rendering when unnecessary is what `shouldComponentUpdate` is for, and while React can't switch it on by default because that would require making lots of unwarranted assumptions about the applications it's used for, nothing stops you from setting up a default `shouldComponentUpdate` based on your own system's invariants.

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`.

ArthurClemens• 11 years ago

Mithril already uses a diffing algorithm: "diffs the new tree against the existing one and intelligently modifies only the portions that have changed": http://lhorie.github.io/mithril/mithril.render.html

lhorie• 11 years ago

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)

habitue• 11 years ago

Yeah, all of the Raynos libraries are really nice and modular. Each one is useful on its own (I think with one exception) without the need for the other Mercury components. It's actually quite a feat.

arianvanp3• 11 years ago

Yep but some could use a bit more documentation love. I should make myself useful...

muraiki• 11 years ago

Yes, the flexibility of virutal dom is really nice. I started to use it with rxjs (Reactive Extensions) only to discover that someone else is already doing so: https://github.com/staltz/cycle

If you really want a functional, stream based frontend in Javascript (vs Elm/purescript/etc), this is well worth looking into. Cycle's author sums up his criticisms of React here: http://staltz.com/dont-react/

smrtinsert• 11 years ago

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

jamestomasino2• 11 years ago

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?

woah2• 11 years ago

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...

jamestomasino2• 11 years ago

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.

ilaksh• 11 years ago

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

arianvanp3• 11 years ago

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

Virtual-dom – A Virtual DOM and diffing algorithm

Related Stories