41–50 of 117 posts
This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
They play to the strengths of the virtual dom approach by manipulating the benchmark via dom instead of what ever interface was implemented within each TodoMVC implementation.
So I forked the benchmark and changed both the Backbone and Mercury implementations to work through their respective apis.
Here it is: https://github.com/smelnikov/todomvc-perf-comparison
as you can see the giant gap between Backbone and mercury is now gone while both tests perform the exact same tasks. (feel free to step through it in the debugger to see for yourself)
Here's my commit log: https://github.com/smelnikov/todomvc-perf-comparison/commit/...
Note: I've added a new method to the Backbone implementation for toggling completed state as the old one was horribly in-efficient. This is not something inherit in Backbone but rather is specific to this TodoMVC implementation. See my comments in the commit log.
Note 2: Exoskeleton, which is basically backbone without the jQuery dependency is roughly 2-3x faster than vanilla backbone, I'm going to predict that it will actually be significantly faster than mercury.
Note 3: I think the virtual dom is great and seemingly has many benefits but I feel as though the speed benefit has been greatly exaggerated.
Earlier quoted context omitted.
Not yet, I've been dying to dig into this for months but now just getting some time to do so. I'm rewriting my blog with lots of cool technologies like this and going to open-source it and write up about it. http://jlongster.com/
Just wanted to add my support with this - I am using React+Fluxxor+ampersand-collections, and I find myself simply rebuilding the collections on every change (and disabling their add/remove/set/reset functions) to keep them immutable and speed `shouldComponentUpdate`, but I would rather be using mori. When you use something like mori, but you need to define data transforms, such as float precision, derived attributes…
I don't know what you mean by "derived attributes", or why it would be difficult to do data transformations on the models that deal with mori data structures. It'd be great to discuss this somewhere, maybe on #reactjs IRC? I'm jlongster there.
This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
If this technique is much more performant (batching diffs of the DOM), why don't browsers perform this "back-buffering" natively?
Also, the fact is that the web is stuck in a Web Components-driven approach to building apps which is pretty orthogonal to how this works.
Having done some benchmarks with TodoMVC before, I knew something was off about these results. They play to the strengths of the virtual dom approach by manipulating the benchmark via dom instead of what ever interface was implemented within each TodoMVC implementation. So I forked the benchmark and changed both the Backbone and Mercury implementations to work through their respective apis. Here it is: https://github…
React originally was designed for developer efficiency and not performance. It is a port of XHP (in PHP) that we use at Facebook to build the entire front-end and we're really happy with. It turns out that the virtual dom and diff algorithms have good properties in term of performance at scale. If you have ideas in how we can communicate it better, please let me know :)
Earlier quoted context omitted.
Our performance benchmarks suggest that application performance is most certainly better off with: (a) DOM reuse (b) calculating expensive things only once (c) reducing GC pressure == not discarding/recreating things (d) coordinating actions that may trigger reflow. It is independent of what framework you are using. My limited understanding of React is that it fails in (a), (b) and (c), and only limited measures can…
(a) You can use the key attribute in order to get DOM reuse. If you are looping over N keys then React is going to reuse the nodes and move them around. (b) You can implement shouldComponentUpdate in order to have a quick way not to re-render a sub-tree if nothing changed. (c) See (b) but we're also working on changing the internal representation of the virtual DOM to plain js objects that can be reused[1]. We were s…
You seem to be an implementor, so two questions that maybe spare me looking at the source code :-)
1. How do you batch updates? 2. I am currently using an algorithm for longest increasing subsequences for avoiding superfluous dom insertions of children when diffing lists. I also make sure that the node containing the active element will not be removed from the tree during the diffing (if possible at all). Are you doing the same?
This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
If this technique is much more performant (batching diffs of the DOM), why don't browsers perform this "back-buffering" natively?
The problem is that it's very easy to force a full recalculate of the whole page layout. Whenever you call .offsetHeight or .offsetWidth or .getComputedStyle, you're doing it. The full list of properties is about 2 dozen strong:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-...
Most web developers don't know this, and so they're actively making their pages slow. Worse, many popular frameworks build this into the library, and so if you use them, there is no way to keep your pages responsive. JQuery, for example, can easily cause 4-5 layouts with a single call to .css; on a mobile phone and a moderately complex page, that's about a second of CPU time.
This technique may be the most revolutionary thing in web development in the last several years, IMHO. I've been using React for a while, and starting to integrate Mori for persistent data structures, and the things I can do with it is insane. The fact that it's not only far better performant, but a way better abstraction for dealing with UIs, is crazy.
If this technique is much more performant (batching diffs of the DOM), why don't browsers perform this "back-buffering" natively?
I've never heard about mercury before! Great to see more virtual DOM development. I hope the new framework gets animation right, I'd love to see it as flexible as in D3, in my opinion this is something currently React currently lacks (the transitions are there but they are too simplistic to cover complex web app cases).