| Author: 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. |
Btw, I just saw this article from the Discourse team on this same topic and was wondering what your thoughts are https://eviltrout.com/2016/02/25/fixing-android-performance....