React 0.14 is going to have similar optimizations. Check those three posts if you are interested in the details :)<p>Reuse Constant Value Types like ReactElement: <a href="https://github.com/facebook/react/issues/3226" rel="nofollow">https://github.com/facebook/react/issues/3226</a><p>Tagging ReactElements: <a href="https://github.com/facebook/react/issues/3227" rel="nofollow">https://github.com/facebook/react/issues/3227</a><p>Inline ReactElements: <a href="https://github.com/facebook/react/issues/3228" rel="nofollow">https://github.com/facebook/react/issues/3228</a>
The performance of Glimmer is amazing, but lets not forget this gem: "backwards compatible with Ember 1.x apps."<p>Here's to a future where our apps get faster without us having to change a thing.
I always have a problem with these kinds of frameworks. Every time I try to use one, and want to do something more in-depth for fancy than a lot of the functionality out-of-the-box, then I end up having to hunt down the way to extend X feature, and it often takes me more effort to do that then just writing in the root language would be.<p>That is to say: The abstraction isn't as expressive as the root language, and when I need something more expressive, then it's more troublesome than writing than the root language.<p>The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I've just been burned a few too many times from this kind of language.
Glimmer is a revolutionary improvement in Ember's rendering performance. I'm incredibly excited by the progress and promise being realized in Tom and Yehuda's PR.<p>For more context, here are a few quick slides from the EmberConf keynote:<p><a href="http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf" rel="nofollow">http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf</a><p>They, and the PR, tell the whole story about what is happening in the dbmonster demo. We expect this work to land in Ember 1.13 stable!
For the curious, here's a port of the Dbmonster demo to a simple Underscore template — the kind of base-level rendering strategy you might <i>start with</i> in a Backbone app. (And vintage 2009 technology.)<p><a href="http://jashkenas.github.io/dbmonster/" rel="nofollow">http://jashkenas.github.io/dbmonster/</a><p><i>Edit:</i><p>To head off grumbling at the pass — It would also be easy to do a slightly less-simple version that keeps the flickering impossible-to-read popups open (putting redundant tooltip DOM into each table cell isn't how you'd actually write this), and the server names selectable ... but those particular "features" don't really seem relevant to this particular UI.
Here is a pretty neat demo with tons of live updates from a firebase cluster: <a href="https://dbmonster.firebaseapp.com/" rel="nofollow">https://dbmonster.firebaseapp.com/</a>
>building virtual DOM nodes for static areas of your markup that will never change for every change requires many more allocations and increases GC pressure.<p>I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? For example, in MithrilJS, you write templates in plain JavaScript, so I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content. Simple.
Quote from wycats during the talk:<p><pre><code> > Because our template language is declarative, we can do this at compile time.
</code></pre>
"This" being determining which portions of the DOM will never change, and so only needing to analyze the portions that might.
It's pretty cool that a year ago, React was far and away the best choice for new JS development for reasons that seemed to be architectural (no dependence on the DOM/server-renderable, isomorphic, intentionally minimal DOM modification), and in the intervening time, the Ember guys have taken the good ideas from React and brought them to Ember. Congratulations! It's great to see the best ideas lifting all boats.
Looks like Glimmer's wits regarding the distinction of static and dynamic parts of the template should be applicable to JST, HAML and the rest as well. The dynamic parts are clearly marked with template tags, and local (changed) variables would be easy to scan for within the dynamic parts of the code. This would probably mean that the template engine should decompose the template into smaller bits, and provide metadata by which the view can map DOM fragments to template fragments (DocumentFragment, DOMNode, DOMAttribute, TextNode) and related Model attributes. Attrubte-level change events could then either directly expire the relevant fragments, or the View onChange/render function would skip repainting the unchanged parts and use appropriate (previously decomposed) fragments of the template function to render changes.
Interesting it's using Handlebars - I wonder how it compares to the diffing done in Ractive, which also uses a similar syntax (<a href="http://www.ractivejs.org/" rel="nofollow">http://www.ractivejs.org/</a>).
I see a lot of talk and comparison to React but nothing about Meteor's Blaze engine and its HTMLJS virtual DOM diffing approach which seems even more comparable
I am not as smart as lot of guys here..but What exactly is Glimmer's additional optimisations other than Virtual DOM?...<p>What exactly does this mean "the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember's APIs to reduce work."??
I feel like the techniques React uses to deal with state and performance are likely to be addressed in a simpler way by solutions that work better with the existing stack. I'm not an Ember user but I like the way they've approached this, without re-inventing the DOM wheel.
So what happens with all those JQuery plugins that manipulate the DOM directly in didInsertElement?
I'm guessing Glimmer doesn't have a clue how to optimize that use case. So a lot of components need to be rewritten from scratch in Ember-style?
> On my machine, the dbmon app in Ember+Glimmer gets 10 renders per second, React gets 14. Not bad, way better than 0.1 per second!<p><a href="https://twitter.com/ryanflorence/status/572991666090467330" rel="nofollow">https://twitter.com/ryanflorence/status/572991666090467330</a>
So how does this compare with Ionic/Angular on mobile? I recently made an app with Ionic, but the 1.0 migration caused gestures to no longer work. Can Glimmer run well on mobile?
What kind of DOM model Ember is using like React.DOM?...I don't think handlebars create DOM Objects?...great to see How Ember accepted the change and implemented that...
Interesting..it has been 10 days Yehuda made that comment and now we come to know about it...or there was discussion before on same which i might have missed?
Yawn. Dust has had all this (and much more) for a long time. <a href="http://akdubya.github.io/dustjs/" rel="nofollow">http://akdubya.github.io/dustjs/</a>