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.
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.
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 :)
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.
Back 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.
Do 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?
Using 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.
I'm not making excuses, but comparing a custom solution like Bloomberg terminals to a versatile platform like the Web is not a fair comparison.
Despite the inherent performance disadvantages, people are stepping up and working on pushing Web applications to run faster. The efforts of the Ember team and others should be commended rather than ridiculed.
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.
One of the motivations for this change was that a real-world application was too slow. As the original presentation says, choosing a technology and then finding out that it's limiting you is really rough when it happens to you.
Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
Performance matters, but if Ember can have 50-60% of the speed of a performance-optimized React app without the associated cognitive overhead, I suspect many will see the trade-off as worth it.
Agreed, for sure. I wasn't trying to make a framework-specific statement, just disagreeing with the notion that performance doesn't matter at all. It may only be for certain kinds of applications, but having more options is always good.
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.
i suppose i presumed a difference of 2x either way (worse/better) to justify picking one over the other -- given that frameworkless is ultimately the most optimize-able.
do you need something to be "at least X(ms) fast" or "faster than what company Y is doing" or "as fast as possible, no exceptions"
