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.
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/
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.
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.
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.
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?
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...
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.
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.
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...
[+] [-] arianvanp|11 years ago|reply
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
[+] [-] muraiki|11 years ago|reply
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/
[+] [-] scoot|11 years ago|reply
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...
[+] [-] zkhalique|11 years ago|reply
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.
[+] [-] habitue|11 years ago|reply
[+] [-] crncosta|11 years ago|reply
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.
[+] [-] zkhalique|11 years ago|reply
[+] [-] BruceM|11 years ago|reply
[+] [-] jamestomasino|11 years ago|reply
[+] [-] woah|11 years ago|reply
[+] [-] worldsayshi|11 years ago|reply
Edit: Ok, I get it. Now we can add this behavior to arbitrary template engines or reactive frameworks, like Meteor for example. Thats awesome.
[+] [-] steveridout|11 years ago|reply
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|reply
[+] [-] rpwverheij|11 years ago|reply
[+] [-] aikah|11 years ago|reply
[+] [-] gondo|11 years ago|reply
[+] [-] ilaksh|11 years ago|reply
[+] [-] arianvanp|11 years ago|reply
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
[+] [-] smrtinsert|11 years ago|reply