Jeff has made it clear that Discourse lacks the resources to dedicate to this problem. The chrome team has made it clear that this is a tough problem with no easy fix, and they have other priorities. Stef’s efforts are heroic but he already has three jobs (Yahoo, core-team, ember-cli).
It appears that Ember in particular, and JS frameworks in general, are in danger of losing their major advantage over native apps. Why not use UIKit if iOS is the only viable mobile JS platform and you have to make a native android app anyway? If you have to support mobile then the only place for JS frameworks is on the desktop.
The Ember community may not have the expertise as a whole to fix chrome on android, but we do have other resources. Can we throw money at the problem? I would pitch in. Bustle puts their money into fastboot; maybe Yahoo, Intercom, Apple, Yapp Labs, Zendesk, LivingSocial, Square, Addepar, Twitch, and Groupon could spare some time or money to form a team to address this issue.
The Discourse meta thread on this topic has ended in resignation that we must wait for newer devices, but a Bountysource might make Ember relevant on mobile prior to 2020. I think we should consider trying to pool our money to make that happen. Other suggestions welcome.
There’s also a lot coming that fixes this issue from Ember’s side, from svelte-builds, to svelte-renders, to glimmer2, to assets loaded via service-worker, to lazy-loaded engines, to threaded apps via skyrocket, to just overall improvements made via optimizations that account for this in ember and ember-data.
You can have a good Android app today if you have a good team. You will have a good Android app in 3-6 months regardless.
For others interested in this topic @jthoburn has several projects that attempt to bring mobile native-caliber performance to Ember apps (and eventually javascript apps in general). Listen to this episode of emberweekend for more details.
At my request he has set up a pledgie for one of these projects, Skyrocket, which you can donate to here.
If we can get enough community support for projects like these mobile web apps and cross-platform apps in general become more viable. Please pitch-in if you can! Thanks.
Personally I’m quite surprised at how little conversation has been stirred up by this. Discourse is one of the bigger Ember.js projects out there. I was hoping more people would talk about how this was the right/wrong move, what other solutions could have been considered etc.
Mostly because while it’s awesome that Ember is flexible enough for you to be able to reach in and do this (and I love that someone demo’d that you can), the timing seems odd. On the surface, it sounds like a large enough undertaking that you would think they would spend more time working on improving incremental rendering solutions for Ember or glimmer2, both of which are very close to landing. I get the feeling they spent significant dev time to land a perf improvement that 6 weeks after release is going to be slower and heavier than if they had done nothing but waited to upgrade Ember.
We’ve tested canary and it’s still 2x slower than Ember 1.11 – which is already punishingly slow on Android. If you’d like to update “complex list” in http://emberperf.eviltrout.com/ to show evidence of this speedup, please do!
I see the reasoning here that if we contributed 6-8 weeks of work to Glimmer that would be better for the community overall rather than Discourse specifically. However, I am skeptical that we could have achieved the same performance benefits by doing so. I am very familiar with Discourse’s code base, and I knew exactly the problem we had to solve. I am not nearly as familiar with Ember, and solving performance in a general way rather than specific way is much harder.
I think you are wrong when you say it will be slower and heavier than if we did nothing. The code should not run slower with Glimmer 2 present, and in fact the rest of our application should go faster with those performance improvements.
Canary doesn’t have the Glimmer 2 stuff enabled yet as it’s still a work in progress. We don’t have any benchmarks right now about what’s in store. I hope when it’s a little more stable to update ember-performance and start testing it.
Have you guys had a look on how Glimmer 2 in Ember 2.9 (currently in beta) affects Discourse performance?
Especially interesting would be comparing Glimmer 2 vs. your homegrown solution. Or is that so specialized that a general rendering engine will never be able to catch up?
I believe @eviltrout checked recently and Glimmer 2 is still many times slower than the VDOM approach.
On iOS this is no big deal as any recent-ish iPhone or iPad is insanely fast, the iPhone 7 renders the Complex List test at http://emberperf.eviltrout.comfaster than my desktop i7-4770k in Chrome latest!
On Android you are in… a world of suffering and pain, sadly. Compounded by the vast number of old/slow Android devices out there.
On Android devices I’ve given up trying to get decent performance with heaps of dom elements. Instead I changed my approach and looked into reducing the amount I was trying to render (and the amount of data I was requesting).
As an example, instead of loading all contacts on the contacts page, I fetched only the first 10 by default and loaded another 10 each time the user scrolled to the bottom of the list. I combined that with some inViewport checking so as the contacts scrolled out of view their component only rendered an empty div.
I also put an inviting search bar at the top that runs a live request to the server.
It’s not always possible to channel user behaviour like that but it might be an option
(Some Android users report up to about 29 score on very new late 2016 Android devices, depending on the vagaries of the browser used. Still below the 2013 iPhone 5s which can be purchased used for about $150 these days.)
Ember.js is one part of the Speedometer test. Let’s drill into that. Here’s the latest version of Ember.js (2.10) comparing Google Pixel phone and iPhone 7, latest updates on all – on http://emberperf.eviltrout.com/
Note that earlier versions of Ember, prior to 2.10 and Glimmer 2, were 15x slower on Android so being “only” 10x slower than iOS is … actually an improvement.
But, good news – they’re looking and they have a new benchmark to target that actually includes ember.js! They’ve said many of the key optimizations in Chrome/Android should land in 2017, probably 1st half.
Let me just say that cough I am SUPER looking forward to the year 2017 for Android/Chrome.
