rxcfc

Scheduled maintenance shouldn't have to mean that _everything_ goes down at once.

Interestingly, I was just talking to someone yesterday about how Yehuda is very good at handing off projects. When he doesn't personally finish something he started, it's because he's handed off the work to someone else who is taking it to completion. I've never seen him abandon any project.

Not yet. It just happened and will need to be post-processed. I'm pretty sure all EmberConf talks will eventually end up online.

Emblem 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.

Performance is a relative term. One could just as well argue that if you're really concerned with performance you should just write machine code.

It'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 :)

Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.

To be clear, while we're using Handlebars syntax, the underlying runtime is not the standard handlebars.js, but a custom version for Ember.

I 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.

In 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.

It'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.

This is only meaningful if Dust has all the other features that Ember templating has.

Ember still uses the Handlebars syntax, but we don't use the standard Handlebars runtime anymore.

You 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.