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.