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.
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)
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 :)
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`.
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.
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.
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).
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...
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.
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.
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.
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."
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.
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.
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...
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