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"
