With low cost, comes even lower performance.
Not always. Ironically the fact that high end Android phones tend to be focused on more cores means their single core performance usually isnât terribly higher than the (good) low cost phones. You just have 2-4 shitty cores instead of 8
Discourse is not a JavaScript app. Sure, thatâs what it is built with, but thatâs not what it is. Wikipedia is not a âPHP appâ any more than Facebook was (and isnât really anymore).
No site owner chooses Discourse because it is built with JavaScript and Ember and whatever else you use.
They choose Discourse because itâs a forum that tries to solve the real problems that regular forums have. And for the most part, itâs an excellent solution that has definitely changed how people think about forums. We donât sell saddles here, afterall.
The technology stack doesnât matter. The user experience (on all devices) does. So make a hybrid solution. Render things server side instead of on the client, so you can instantly send down the entire cached page sans the user icon in the menu, and then load that in afterwards (along with anything else). Once the initial page load is over it seems like Android performance isnât nearly as bad. Iâm not an expert on how things work under the hood, so itâs just my uninformed two cents.
Personally Iâve always thought a true official Discourse mobile app, where users can subscribe to any Discourse forum and get notifications, offline sync, and significantly better compose options, would be a much better solution for actually interacting on a mobile device.
You could also give forum owners the option to use ads in stream, which would give people a real option for monetizing their forum without being too intrusive. And you could provide a Discourse forum directory to help with discovery, or even source really interesting discussion topics across the web, which would be fascinating.
Yeah, itâll cost money to create the apps, but it would probably be worth it in the long run. And everything works against the Discourse API so youâre just building a front-end.
But even if you have the mobile app it wonât change the fact that initial page load performance on Android isnât a good experience.
All well and good, but
Ultimately one platform would always lag behind (most likely the android app) and it wouldnât be a better experience, just a different kind of issue. If individual sites want to use the discourse API to make their own apps thats one thing, but Iâm not sure having a global discourse app is really that great of an idea even if the manpower and resources existed.
I remember Twitter going through the server side rendering process and reading about Ember having started âFastbootââŠ
Did Emberâs Fastboot implementation make it into the current Discourse version?
Did it help? Would it help at all?
fastboot is no where near close to production ready at this stage, if you look at the repo on github they havenât even gotten it serving JS assets yet. In addition to that, fast boot would only help with initial page load as itâs only designed to render the initial page and let the front end app take over from their. Fast boot is definitely something Iâd like to see in discourse eventually, but itâs nowhere near ready at this stage, and wouldnât solve the overall issue of android performance being subpar
At least Chrome supports the push api. Push notifications are an essential feature of a mobile app. With iOS you may get near native app performance, but not a near native app experience.
One of the things that I think worth mentioning, is that most users will never have experienced the other side of the OS divide. By this, I mean if theyâve always used Android (like myself), they will be used to the (relatively) slow rendering of JS heavy sites like discourse. If theyâve always used iOS, then theyâre used to the (relatively) fast rendering.
In other words, donât compare Apples to Oranges. Most users wonât. Most users will compare their new shiny orange to their old, mouldy orange.
Thatâs not to get away from the fact that the performance is significantly worse on Android. It is an issue, and something to keep considering from a development point of view. Iâd assume that with server side rendering of pages (or similar), a technique is available to work around this. But the end users of the product probably (Iâd say wonât, but I donât have any facts to back it up) donât care. I already find the performance of discourse incredibly better on mobile than any other forum product Iâve used Keep the good UX and people will keep using it is my guess.
that would be true if all websites were JS apps, but theyâre going to be comparing Discourse against other sites that are not JS apps and any discourse site is going to feel like a bad experience in comparison. Just like the average use wonât know how much better JS sites work on Apple, they wonât know âOh, this is a JS site, and therefore I should excuse itâs poor experience because all JS sites are like this.â the average user just knows that this site doesnât feel as snappy as these other sites and itâs a poor experience over all.
So, granted, FastBoot is not yet production-ready. But it is headed in that direction, with several companies working on getting it to that state and planning on using it sooner rather than later.
I wonder:
- Would FastBoot help with this problem?
- Might it actually be better to always force Android devices into a perpetual-FastBoot mode? E.g., never loading the JavaScript and always hitting the server for a different page? It seems a shame, given how much cool stuffâlike Service Workerâis available on Chrome for Android. But itâs hard to argue with the awful performance.
- Not out of the box even when itâs done. This isnât a problem fast boot is fundamentally meant to solve.
- We donât know what Fast Boot will end up looking like beyond a general product outline, so my instinct would be to say no it would be more trouble than itâs worth. Youâre talking about using fastboot to essentially force an ember app to be a static site based on the device thatâs visiting the site. That sounds messy on itâs face, and what if Android DOES get itâs act together some day? Now you have to force older devices to the static site, but newer ones to the Ember app.
Discourse isnât the fastest thing ever on my devices ( Moto X 2014, Galaxy Tab S 2014 Custom ROM) but is fast enough.
What I mean? It loads faster than Facebook.com, so everyone is used to wait a bit on first load. After that everything is smooth if you are using a reasonably recent device.
Maybe a react native/java app can squeeze most performance? Yeah but is it a show stopper or just a plus?
Has anyone benchmarked Discourse on the Android M preview?
Weâve done enough research to know this issue is not really specific to Ember, but also affects Angular and most other heavy/complex JavaScript on Android.
Could you reveal some more details of this research? Which JS frameworks were tested? Whis one is the fastest? Which one is the slowest? Are there any numbers avaialble?
Thanks!
This is becoming more and more of a systemic problem in the Android ecosystem, one that will not go away in the next few years, and it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices. That is clearly happening on iOS but it is quite disastrously the opposite on Android.
A large portion of the world uses low-end Android devices, which is why apps like Facebook Lite exist (which has gained hundreds of thousands of users in just a few months). If you want to have wide reach to as many users as possible, youâre going to eventually need some sort of lighter version that uses server-side rendering rather than client-side.
John Gruber suggests:
I donât think itâs because Android manufacturers are cheaping out, as Atwood implies. I think itâs because Bob Mansfieldâs team inside Apple is that far ahead of the rest of the industry.
Iâm a JavaScript Developer myself, and I understand the problem with attempting to get JavaScript heavy sites working smoothly on Android devices.
However, I donât think itâs as large of a problem as you make it sound. I think Android devices, while it does seem like Qualcomm is pushing more cores, have a bright future with JS. There is also a lot of work being done on JavaScript engines and cpu architectures to utilize multiple cores in single threaded processes like the event loop. The Spidermonkey code monkeys are already making some progress in this area.
I donât know the workings of Discourse, nor do I have any experience with ember. I think you should try building a very thin client that works with mostly static pages, maybe with some JS for menus, and using paginated posts. Use CSS transitions whenever possible. Thereâs really not much else I can recommend without getting a good look at what youâre doing already. (I have plenty on my plate anyhow)
Hi Jeff,
long time fan
Have you guys looked at React; You can push the same code client side as well as render it on the back end (isomorphic javascript);
I would go with figuring out what is the heaviest piece of perf code and see whether i can recreate it with react and remeasure performance.
The new android react native would have been an interesting option if you guys had an option to rewrite