I didn't see the author at any point question the performance of their JS framework. More specifically, it seems like the author is using Ember for their apps. My (very rough) understanding is that Ember tends to have a lot of issues running on V8. Due to the way Ember is written, V8 tends to have a hard time optimizing for it.
Where the other libraries all cluster around the same framerate, Ember is running in the single frames. I know that benchmarks can be written in a way to make one library look pathological so this is just one data point, but I wanted to throw it out there. I agree that it would be great if V8 and Ember played better together :)
You might be onto something here. Jeff Atwood posted several months ago about Android's suboptimal JavaScript performance in the context of Discourse [1], and that also uses Ember. I wonder what characteristics of Ember might make it suboptimal under V8.
I was actually spelunking through the Angular source the other day, when I came across a comment noting that Angular avoids using closures for information hiding, due to their poor performance characteristics. Instead, they prefix private variables with a $$ prefix and leave them exposed to developers. Perhaps the Ember team made a different decision in this regard (NB: I don't mean to suggest that this is the sole reason for the difference in performance, just that these might be the kinds of decisions that matter).
You have a good point. Ember triggers a weakness in V8's optimizations causing repeated optimizing and de-optimizing of core Ember functions, which takes time and generates lots of garbage, and V8 should fix that.
My understanding is the V8 team _is_ attempting to fix Ember (and Ember-style code) performance on multiple fronts, things like adding an interpreter, tuning how opt and de-opt are triggered, maybe adding dev tools that make it clear when script is spending time de-opting. Probably the most important thing would be to get more realistic workloads into benchmarks.
Ember does appear to be a pathological case though. Every other framework of similar size has managed to attain decent performance on Chrome.
One take-away here is that JS developers should not assume that all code is fast in all VMs. Optimizations are often (very educated) guesswork, and developed and tested against some corpus of benchmarks. If you use a pattern that isn't common in the benchmarks, you might trigger an unexpected problem. Framework developers should measure performance across browsers early, before baking in any hard to change design decisions.
I've worked on a fairly complex web app with advanced graphic effects. It used Angular, and I can confirm anything this article says, and more. For instance, it's extremely complex to get a CSS animation perform reasonably well on Android, compared to old iPhones.
I don't think V8 is a problem per se, it's the whole browser that underperforms on mobile. The only positive point is that at least it updates quickly. Sometimes minor versions of iOS introduces bugs that you don't ever know when they will be fixed.
Re Questioning Ember:
I've questioned it many times (and vocally, but within the community itself where I'm an active member). This article is about something much bigger than my framework of choice.
On the comparison above:
I've called this one out before, it's a very poorly built Ember app that's also running a version from nearly 2.5 years ago, before Ember invested a ton of time in building a very fast rendering engine, there's no end of dbMon demos showing Ember at or above the speed of the other major frameworks, and we'll be seeing a new one soon with Glimmer2 landing.
On Ember:
Ember does take an initial performance hit, but unlike other frameworks it tends to give you fairly constant time performance as your apps and features grow. This initial hit is something Ember is working furiously to fix (and I might add a lot of that is directly due to Mobile Chrome performance). Glimmer2 (the brunt of the v8 focus), app shell architecture, code splitting, and tree shaking are all concepts that will be built into every Ember app within a few months.
On a more "app specific" note, I've been working on making occlusion, recycling, and parallelism simple and easy to work with at the framework level in Ember apps, much of which enabled entirely because of Ember's conventions and approach. Generally speaking, I've been able to build mobile and hybrid apps in Ember that are more performant than anything I've seen so far via other mobile and hybrid approaches... except for Android.
On The Article:
I didn't talk about Ember much because my experience with this goes far beyond Ember (or Angular, the other framework that hits these problems more often). The point is that for anything other than simple JS applications, building a great app for Mobile Chrome is extremely difficult to pull off, and it becomes a large cost for app developers and has led to the rise of huge investments in OS solutions just for dealing with it alone.
A point that I didn't talk about much, but which is something you see more in SPAs and hybrid (ala Ember/Angular) is that honestly, 1MB and even 2MB JS apps shouldn't scare us the way they do right now.
Yes, I do agree that it's a lot of JS to ship to a browser, and tree shaking, code splitting, and app-shell will help us deal with that. Yes, I also agree that we shouldn't be asking our users to download 2mb of Javascript to see one page.
But the bet on this architecture goes beyond one page, the moment you hit page 2, every page hit is a performance win over the last. And with ServiceWorkers, this story will only get better. While progressive enhancement is awesome, and will always have a place, full blown apps delivered by the web do too, and full blown apps are very rarely 250kb of Javascript.
What was the last native app you downloaded that was 250kb? And (just name names), when was the last time you looked at how big Facebook's native app is? When it comes to JS apps, we're competing with native, it's naive to think we'll be keeping our JS to such a tiny payload for all time.
I don't know which version of Ember the author is using, but note that last year Ember introduced a new rendering engine called glimmer which performs much better on the same benchmark:
[1]: https://meta.discourse.org/t/the-state-of-javascript-on-andr...