6 ms·

Virtual-dom – A Virtual DOM and diffing algorithm

142 points by cleverjake 12y ago

worldsayshi 12y 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 12y ago
  license if not anything else
  - worldsayshi 12y ago
    React is Bsd, this one is also bsd-ish? edit: why downvotes?
    - beefsack 12y ago
      Facebook has some nasty patent terms in their open source projects.
      - worldsayshi 12y ago
        Wow, yeah. Read the PATENT file in a bit more detail now. Could be a problem.
    - bildung 12y ago
      > React is Bsd, this one is also bsd-ish? But this one comes without Facebooks patent clauses. Edit: Apparently that was too terse: While Facebooks React comes as BSD, the patents clauses are so broad that questioning software patents in a blog post would result in licence revocation. They are not just litigation defense like the ones from the Apache Foundation: "The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim [...] alleging [...] that any right in any patent claim of Facebook is invalid or unenforceable."
      - _delirium 12y ago
        It is probably the case (but not guaranteed) that a court would read "makes any claim" a bit more narrowly to mean only legal claims, not blog posts. It's a common phrase used in e.g. statutes as a term of art, and usually taken as narrower than a phrase like "expresses a view". However it would almost certainly still include USPTO administrative challenges (e.g. challenging a patent by demonstrating prior art), which is still a big problem.
      - ksherlock 12y ago
        This comes without any patent grants whatsoever. If you're worried that Facebook has patents covering react, you should probably be worried that they have patents covering this code as well. If you're worried about the patents, you should use react or use neither.
- rpwverheij 12y ago
  exactly.. Just in case you want virtual DOM, but not the rest of React, this comes in very handy
- aikah 12y ago
  Because choice is good. The Javascript world is definitely not a mono culture, get used to it.
  - worldsayshi 12y ago
    I wasn't rejecting it. I was curious.
- steveridout 12y 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/virtual-dom.js 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 12y ago
  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 12y 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 12y ago
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 12y ago
  Well it seems this patent is only there for defensive purposes.
  - _delirium 12y 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.
    - k__ 12y ago
      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"
arianvanp 12y 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 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
- scoot 12y 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.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
- zkhalique 12y 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 12y 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`.
smrtinsert 12y 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.
jamestomasino 12y 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?
- woah 12y 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-object-with-browserify/ http://www.mattburkedev.com/export-a-global-to-the-window-ob...
  - jamestomasino 12y 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.
    - woah 12y ago
      Well, the example is CommonJS, not AMD.
ilaksh 12y ago
Maybe someday the real DOM will perform and we won't need this type of thing.
- arianvanp 12y 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 https://github.com/atom/atom/pull/5624

142 points by cleverjake 12y 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 12y ago
license if not anything else
- worldsayshi 12y ago
  React is Bsd, this one is also bsd-ish? edit: why downvotes?
  - beefsack 12y ago
    Facebook has some nasty patent terms in their open source projects.
    - worldsayshi 12y ago
      Wow, yeah. Read the PATENT file in a bit more detail now. Could be a problem.
  - bildung 12y ago
    > React is Bsd, this one is also bsd-ish? But this one comes without Facebooks patent clauses. Edit: Apparently that was too terse: While Facebooks React comes as BSD, the patents clauses are so broad that questioning software patents in a blog post would result in licence revocation. They are not just litigation defense like the ones from the Apache Foundation: "The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim [...] alleging [...] that any right in any patent claim of Facebook is invalid or unenforceable."
    - _delirium 12y ago
      It is probably the case (but not guaranteed) that a court would read "makes any claim" a bit more narrowly to mean only legal claims, not blog posts. It's a common phrase used in e.g. statutes as a term of art, and usually taken as narrower than a phrase like "expresses a view". However it would almost certainly still include USPTO administrative challenges (e.g. challenging a patent by demonstrating prior art), which is still a big problem.
    - ksherlock 12y ago
      This comes without any patent grants whatsoever. If you're worried that Facebook has patents covering react, you should probably be worried that they have patents covering this code as well. If you're worried about the patents, you should use react or use neither.
rpwverheij 12y ago
exactly.. Just in case you want virtual DOM, but not the rest of React, this comes in very handy
aikah 12y ago
Because choice is good. The Javascript world is definitely not a mono culture, get used to it.
- worldsayshi 12y ago
  I wasn't rejecting it. I was curious.
steveridout 12y 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/virtual-dom.js 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 12y ago
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 12y 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 12y ago

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 12y ago
Well it seems this patent is only there for defensive purposes.
- _delirium 12y 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.
  - k__ 12y ago
    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"

arianvanp 12y 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 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

scoot 12y 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.html http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
zkhalique 12y 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 12y 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`.

smrtinsert 12y 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.

jamestomasino 12y 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?

woah 12y 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-object-with-browserify/ http://www.mattburkedev.com/export-a-global-to-the-window-ob...
- jamestomasino 12y 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.
  - woah 12y ago
    Well, the example is CommonJS, not AMD.

ilaksh 12y ago

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

arianvanp 12y 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 https://github.com/atom/atom/pull/5624