18 ms·
Ember's Glimmer Engine
- makmanalp 12y agoHere is a pretty neat demo with tons of live updates from a firebase cluster: https://dbmonster.firebaseapp.com/ https://dbmonster.firebaseapp.com/
- jpdlla 12y agoDemo's source code: https://github.com/wycats/dbmonster/ https://github.com/wycats/dbmonster/
- fortytw2 12y agoThis is simply incredible. That's some insane rendering performance coming out of this.
- ckluis 12y agoIndeed, that is pulling some serious update info at an insane speed.
- amccloud 12y agoDemo of embers original performance with dbmon along with angular and react https://www.youtube.com/watch?v=z5e7kWSHWTg https://www.youtube.com/watch?v=z5e7kWSHWTg
- baddox 12y agoAre there demos and/or source code for the Angular and React implementations used in that presentation? I'd like to compare React to this new Ember implementation, because the latter, while better than the Ember demo in that presentation, is still noticeably sluggish on my machine.
- lh 12y agohttps://github.com/ryanflorence/reactconf-2015-HYPE/tree/master/demos/01-dbmon https://github.com/ryanflorence/reactconf-2015-HYPE/tree/mas...
- STRiDEX 12y agoWould take with salt. The angular version doesn't use track by https://docs.angularjs.org/api/ng/directive/ngRepeat#tracking-and-duplicates https://docs.angularjs.org/api/ng/directive/ngRepeat#trackin... These demos are like listening to MongoDB talk about how great MongoDB performs. Always better to look for yourself or check a trusted third party. Here's an angular dbmon that is at least using track by. I didn't write it. http://run.plnkr.co/plunks/Uu7w8p7jiPEJp5lLHWbB/ http://run.plnkr.co/plunks/Uu7w8p7jiPEJp5lLHWbB/
- ZaneD 12y agoHere is the original Ember version: http://jsbin.com/pafoledixe/2/ http://jsbin.com/pafoledixe/2/ Be careful, it is very slow and may crash your browser.
- IanDrake 12y agoReact Version: http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/ http://run.plnkr.co/plunks/Wwgjjpl9NHMO5Nd1TUyN/
- Numberwang 12y agodo you have a source for this?
- fooey 12y agohttp://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN http://plnkr.co/edit/Wwgjjpl9NHMO5Nd1TUyN
- pikzen 12y agoThis demo is taking up an entire core of an i5 2500k. To update a table. It barely updates once every two seconds on a three years old phone. My terminal is faster than that and doesn't even use 1%. A native application is faster than that and barely uses 1%. I know this is a nice advance for client side rendering, but can we stop pretending it's in a good state ? (Although if you're updating this many times per second your application, you might be having a problem already.)
- rxcfc 12y agoIn regards to taking up an entire core, it's updating as fast as it possibly can, it's basically a stress test. In practice, updating this quickly isn't useful, you would want to throttle it for production use. It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.
- slacka 12y agoBack in college I used to see 486 Bloomberg terminals updating more complex tables in real time with no perceivable lag. It's a sad reflection on bloated HTML5 technology that it can only deliver this level of performance with CPUs that are literally thousands of times faster.
- ralmidani 12y agoDo Bloomberg terminals use an off-the-shelf framework (vs. custom, proprietary code) and run on the open Web (vs. a private network)? What is easier for someone with no degree and little experience, programming a Bloomberg terminal or building an Ember app?
- Cthulhu_ 12y agoUsing custom code or running on the Web are both not valid arguments for poor performance; in the given example, rendering in something else than a table (like, say, a custom canvas view) would already improve performance by miles. Running in a terminal (stream via ssh) would also be fasterer.
- mixonic 12y agoGlimmer 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. For more context, here are a few quick slides from the EmberConf keynote: http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf 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!
- msane 12y agoI needed improvements in Ember's rendering performance a year ago, back when performance improvements were already behind schedule. A situation which still remains in production Ember today: http://youtu.be/z5e7kWSHWTg?t=2m42s http://youtu.be/z5e7kWSHWTg?t=2m42s It's too little too late for me. I wouldn't want to touch anything Ember or anything from the authors.
- mixonic 12y agoI also needed improvements. So I shipped the code to make them happen! Very proud of our progress. I hope the stability and reliability of Ember's process, and its continuing improvement, will tempt you back.
- msane 12y agoYes, you're right. It's my fault for not pitching in. I should have worked my way in to the core team and fixed it myself, rather than selecting one of the other performant frameworks available. > the stability and reliability of Ember's process I'm aware you're one of the people who finally got it done, kudos. But the chances of going back to Ember are nonexistent. This was my experience with Ember: http://discuss.emberjs.com/t/when-will-htmlbars-be-ready/3155/58 http://discuss.emberjs.com/t/when-will-htmlbars-be-ready/315... * 08/2013: Unusable performance when displaying listviews with over 20 items, without infiscroll (unofficial and poorly supported, or roll-your own). Promises that it will be resolved in next months. * 08/2014: Still getting the runaround about when those "improvements" will arrive. Only one of a dozen things which made working with Ember horrific. Apologies for being bitter, but it is what it is.
- hswolff 12y agoGotta say, the incremental improvement pattern Ember is adhering to is absolutely the bee's knees. Kudos Ember team, so awesome to see!
- anarchy8 12y agoCan we have a side-by-side comparison of the same demo using normal Ember?
- wycats 12y agoIt's slow. Real slow. The original demo really stressed Ember's pathological cases, so it was a great thing to keep in mind as we developed Glimmer.
- cnp 12y agoI saw the original at a Meetup a while back and it was crash-the-browser slow. This is far improved.
- myared 12y agoThey showed that side by side. Imagine the page reloading every 2 seconds instead of at the rate it is now. The improvement is incredible to see.
- chacham15 12y agoI dont know if this is exactly the same app, but it looks like it: http://youtu.be/z5e7kWSHWTg?t=5m07s http://youtu.be/z5e7kWSHWTg?t=5m07s (ember is on the left, then angular, then react)
- cfontes 12y agoNever used ember but that deserves a pretty complete write up about what was done and how. Nice work.
- steveklabnik 12y agoHere's a TL;DR: A handlebars template might look like this: <div class="foo"> {{#if enabled}} <p>I'm enabled!</p> {{#end}} </div> The usual DOM-diffing algorithm compares every single thing: "has this div changed? Has the class changed? Has the <p> changed?" This uses the knowledge of Handlebars to make the diffing algorithm smarter: you don't need to check if the <div> or its class has changed, it never will. You don't need to check if the <p>'s contents have changed, it never will. This means less to diff, which means more speed. This is the advantage of using a declarative syntax for templating: this analysis can be done entirely at compile time.
- searls 12y agoThanks for the concise description. Love to see Team Ember take advantage of the information users are already feeding the existing public API.
- ssutch3 12y agoI imagine we'll get something soon. Ember is having it's developer conference this week, and they were planning on announcing this and I believe something related to a server-side trampoline of sorts.
- steveklabnik 12y agoThis link was posted short after the keynote, this was announced, as well as more information about FastBoot, the thing you're talking about: http://emberjs.com/blog/2015/01/08/inside-fastboot-faking-the-dom-in-node.html http://emberjs.com/blog/2015/01/08/inside-fastboot-faking-th...
- rxcfc 12y agoSome information can be seen at the PR for Glimmer: https://github.com/emberjs/ember.js/pull/10501 https://github.com/emberjs/ember.js/pull/10501.
- steveklabnik 12y agoQuote from wycats during the talk: > Because our template language is declarative, we can do this at compile time. "This" being determining which portions of the DOM will never change, and so only needing to analyze the portions that might.
- nathansobo 12y agoIs the talk online?
- rxcfc 12y agoNot yet. It just happened and will need to be post-processed. I'm pretty sure all EmberConf talks will eventually end up online.
- mmgutz 12y agoWill this be built into handlebars or just ember?
- ChrisGaudreau 12y agoJust Ember. I'm pretty sure Ember doesn't even have a dependency on Handlebars anymore. (possibly only off stable)
- rxcfc 12y agoEmber still uses the Handlebars syntax, but we don't use the standard Handlebars runtime anymore.
- untog 12y agoInteresting it's using Handlebars - I wonder how it compares to the diffing done in Ractive, which also uses a similar syntax (http://www.ractivejs.org/ http://www.ractivejs.org/).
- rxcfc 12y agoTo be clear, while we're using Handlebars syntax, the underlying runtime is not the standard handlebars.js, but a custom version for Ember.
- dracolytch 12y agoI 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. 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. 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.
- jjbiotech 12y agoYeah, I think what you just stated is an issue for any type of abstraction. You really just have to examine an interface in depth before you start writing code with it to see if it's capable of supporting the functionality you need. Only a few months ago while developing a REST API in Ruby, I implemented MongoMapper for my ORM/Database access layer. Turns out it didn't support a few things I wanted to do, so I hacked my code into little (ugly) pieces just so I could continue using MongoMapper (Didn't have time for a rewrite). I think if I would have just stuck with using the native Ruby Mongo driver, development would have taken less time and my code wouldn't look like a steaming pile of shit!
- emodendroket 12y agoWell, you know, the native Ruby Mongo driver and Ruby itself are both abstractions, too.
- untog 12y agoEvery framework has a learning curve. In this instance it seems to have a significant performance benefit. That's your trade-off.
- aero142 12y agoI didn't take his comment to be about a learning curve. I think the complaint is that the abstraction on top is not as expressive as the thing it abstracts. This means that when you break the abstraction you have the complexity of the thing you abstracted away on top of the abstraction layer itself, which means you might have been better off without the abstraction in the first place.
- praxxis 12y agoThe performance of Glimmer is amazing, but lets not forget this gem: "backwards compatible with Ember 1.x apps." Here's to a future where our apps get faster without us having to change a thing.
- steveax 12y agoIndeed. I continue to be impressed at how painless keeping current with ember in our application has been.
- desireco42 12y agoYeah, I am not huge fan of Ember but this is genuinely nice to have and I noticed it.
- vjeux 12y agoReact 0.14 is going to have similar optimizations. Check those three posts if you are interested in the details :) Reuse Constant Value Types like ReactElement: https://github.com/facebook/react/issues/3226 https://github.com/facebook/react/issues/3226 Tagging ReactElements: https://github.com/facebook/react/issues/3227 https://github.com/facebook/react/issues/3227 Inline ReactElements: https://github.com/facebook/react/issues/3228 https://github.com/facebook/react/issues/3228
- ralmidani 12y agoReact's unfair and one-sided patent grant aside (personally, I will never build a real app with React unless that situation changes), it is not a complete MVC framework, and to my knowledge there is nothing that fills in the gaps to make something close to Ember feature-wise. So while React may end up faster, Ember will hopefully be quick enough that its programming model wins out. Edit: grammar.
- rxcfc 12y agoIt's also worth noting that we're getting to the point where fastest doesn't really matter. Both Ember and React will be fast enough. Performance shouldn't be a deciding factor.
- rxcfc 12y agoI should have added the caveat that there will always be a handful of cases where you do need absolute top performance. However, I do think that for the vast majority of apps we'll end up at a point where performance isn't the deciding factor. It doesn't mean that we shouldn't keep improving performance, just that being the fastest doesn't matter so much if all the options are very fast.
- hayksaakian 12y agoit seems like if you're concerned with performance, react vs ember is not the conversation you're having. your concern would be whether to use a framework at all
- virmundi 12y agoSo 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?
- quaunaut 12y agoMy try with it was anecdotal, but the demo[1](which is a pretty brutal demo) ran at a fair speed on my phone- about 3 updates per second. Currently, on Android devices most complex JS apps have performance issues(some problems were found in how Android processes JS), but this should go a long way in mitigating that problem while it's worked on by Google.
- nwienert 12y agoI'll go ahead and plug myself here only because it's very relevant, but if you want to play with a full-stack for building mobile apps using virtual DOM, check out http://reapp.io http://reapp.io
- some1else 12y agoLooks 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.
- iamleppert 12y agoYawn. Dust has had all this (and much more) for a long time. http://akdubya.github.io/dustjs/ http://akdubya.github.io/dustjs/
- lightblade 12y agoI thought dust is still using string concatenation. Has this changed and when?
- rxcfc 12y agoThis is only meaningful if Dust has all the other features that Ember templating has.
- theflop 12y agoSo 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?
- grandalf 12y agojust remove those
- awj 12y agoWell, if you need the performance increase, the yes. Otherwise your options are to (maybe) tweak your current implementation so it continues to work or rewrite the functionality to be compatible with the view layer. This is the same trade-off you make with React since it's basically the same technology.
- rxcfc 12y agoYou shouldn't be both manually manipulating the DOM _and_ using Handlebars mustaches for the same element. Since there wouldn't be mustaches, Glimmer would ignore these cases. In general, you should only be using jQuery plugins for special cases not covered by Ember anyway.
- theflop 12y agoSo 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?
- davexunit 12y ago>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. 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.
- colinramsay 12y agoYou appear to have been downvoted; while I don't know whether your potential solution is right or wrong your downvoters should have been polite enough to explain their reasoning.
- mixonic 12y agoI am confused what is being suggested. > virtual DOM nodes for static areas of your markup refers to React's virtual DOM implementation, not Ember's. > I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? Ember is a complex framework. Suggesting a "solution" to challenges with an acknowledged lack of context, and adding "Simple", shows fairly poor attitude. > I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content This sounds pretty much like what is already described in the PR. Again, still confused, and still don't know what is being suggested.
- tessierashpool 12y agoI hope someone makes you an admin! yesterday, I got downvoted repeatedly for mentioning that I hadn't seen an IIS header in years. ¯\_(ツ)_/¯
- simplify 12y agoCould you provide an example?
- Cakez0r 12y agoI believe they're saying that a virtual DOM is created and updates that would cause a re-render are first applied to the virtual DOM (thus avoiding the over head of a render). The virtual and actual DOM are then compared to see which parts have changed and need to be re-rendered, which results in a net saving of CPU time. There is no constant value to store here. Perhaps you are referring to the templates, which are static and are already stored in memory?
- jashkenas 12y agoFor the curious, here's a port of the Dbmonster demo to a simple Underscore template — the kind of base-level rendering strategy you might start with in a Backbone app. (And vintage 2009 technology.) http://jashkenas.github.io/dbmonster/ http://jashkenas.github.io/dbmonster/ Edit: 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.
- ebryn 12y agoUnfortunately your example isn't a full reproduction as both the Ember/React examples reuse existing DOM which is important for selection state and the popover functionality.
- rxcfc 12y agoIt's pretty cool to see that Ember is still in the same ballpark, especially when you realize that Ember does a ton of stuff that Backbone doesn't do for you :)
- emmanueloga_ 12y agoTangentially: (yet somehow related), you could write [1]: > The process of converting a string template into a fully compiled HTMLbars template function that emits DOM nodes is somewhat involved. The purpose of this document is to shed some light on the process and describe where in the HTMLbars codebase these steps take place. or you could just write: > OVERVIEW If the parallel is not obvious, it feels like many JavaScript frameworks are written in this overly verbose style. 1: https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE.md https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...
- itsbits 12y agoyou might want to look into this timelines https://news.ycombinator.com/item?id=9149475 https://news.ycombinator.com/item?id=9149475
- bsimpson 12y agoIt'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.
- pothibo 12y agoIs that DBMonster app becoming the new todo app for all JS framework to implement?
- hayksaakian 12y agoi think the todo app is a good demonstration of the specific code necessary to accomplish a standardized task. DBMonster is more like a standard performance benchmarker.
- cellis 12y agoBut will it work with Emblem? Also how does this affect FastBoot?
- rxcfc 12y agoEmblem compiles to Handlebars so it will gain all of the benefits of Glimmer. FastBoot is only concerned with the initial render which is done on the server. Glimmer is concerned with updates so it will not directly affect FastBoot but will work with it.
- randomguy7788 12y agong2 will have similar optimizations i believe. interesting times in the 2.0 framework wars! lol i kidddd
- spyc3r 12y agoAngular 2.0 has similar optimizations but sacrifices backwards compatibility. Glimmer is still backwards compatible with Ember 1.x.
- Rapzid 12y agoWill these virtual DOM/diff'ing optimizations be built into the browsers at some point? Seems like they should/would.
- seanmcdirmid 12y agoYou'd think that with a proper background rendering thread, they could get away with a retained scene graph maintained via dirty bits. But obviously, I'm missing something: what is it about the DOM that makes changes so expensive that they have to be batched via a virtual one?
- woah 12y agoIt has to calculate layout, while the virtual DOM does not.
- seanmcdirmid 12y agoCan't it batch layout calculations like is typically done in a retained scene graph? You don't do the layout calculations on each change as they occur! Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal of width, and so on), but the perf is pretty good.
- seanmcdirmid 12y agoThere is a SO post on this: http://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode http://stackoverflow.com/questions/21109361/why-is-reacts-co... Some points: > Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively. You don't have to poll your dirty bits! When you dirty something, you put it into a dirty list/set. You only re-render if your dirty list/set is not empty, clean deeper elements before shallow elements, and its quite optimal. > A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene. Totally: they are basically turning a retained model into a not-so-slow immediate model, which is a nice programming abstraction, but it is not a performance win over an efficient retained model. > DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM. So layout calculations in normal DOM aren't incremental, but are made incremental in virtual DOM? Assuming this isn't related to batching, it sounds like the concrete DOM is just a bad implementation? Or does the virtual DOM avoid doing layout calculations at all and somehow magically fixes the layout when things change?
- drderidder 12y agoI 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.
- itsbits 12y agoInteresting..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?
- ohfunkyeah 12y agoI see a lot of talk and comparison to React but nothing about Meteor's Blaze engine and HTMLJS which seems even more comparable
- ohfunkyeah 12y agoI 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
- EugeneOZ 12y agoSo mutable structures can be powerful too, when handled right :)
- itsbits 12y agoWhat 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...
- zeppelin 12y agoHandlebars doesn't, but HTMLBars does indeed [generate][1] DOM objects from Handlebars AST - it's basically another compile step. Check out section 2 and 3. [1](https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE.md https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...)
- itsbits 12y agoI see that HTMLBars is building more of Document fragments rather a single DOM tree. Would be interesting to check if all these document fragments are independent to each other like 1000's of HTMLBar views inserted directly into the Ember Application as siblings rather as a tree. There will be lot of memory involved than when you use a single DOM tree. isn't it?
- itsbits 12y agoI am not as smart as lot of guys here..but What exactly is Glimmer's additional optimisations other than Virtual DOM?... 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."??
- flexterra 12y agoEmber's templates allows the framework to determine which portions of the DOM will never change, and so only needing to analyze the portions that might. <div class="container"> <-- this won't change <h1>Hello World</h1> <-- this won't change <div>{{name}} <-- this might change </div> </div>
- itsbits 12y agoWow..Thanks a lot..Now I understand the sentence.. But I think now this may force us to use more handlebars. Manipulations in didInsertElement may get affected as well. Like updating classes which I sometimes prefer doing in hooks like click, didInsertElement.
- drogus 12y agoThis is irrelevant to the changes from the PR. Manual DOM updates are not managed by HTMLBars anyway, regardless of the rendering algorithm. That said, I think that binding classes (like `class={{foo}}`) and updating it through HTMLBars is a safer way to do it, comparing to direct DOM manipulation.
- iamstef 12y agoAdditionally, rather then having a "virtualDOM" we build a tree of the dynamic data. This is more or less diff'ed similarly to how the virtualDOM is diff'ed. But where it get interesting is when it comes to actual DOM interaction. To create DOM, we use document fragments + cloneNodes, but for granular updates we utilize property/attribute/textContent updates. When used correctly, this combination turns out to be very fast. As a bonus, we are typically able to utilize the browsers built-in XSS and sanitization (or just lack of parsing) rather then having to implement this slowly in JavaScript ourselves. Ultimately, I am extremely happy with how the various front-end frameworks keep pushing the envelope. Getting faster, easier to use, and more secure. Ultimately regardless of the framework the ecosystem moving forward benefits the end users the most.
- lightblade 12y ago> 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! https://twitter.com/ryanflorence/status/572991666090467330 https://twitter.com/ryanflorence/status/572991666090467330