With low cost, comes even lower performance. 
That was covered upthread:
1 Like
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
1 Like
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.
11 Likes
All well and good, but
3 Likes
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.
2 Likes
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?
1 Like
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
1 Like
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.
8 Likes
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.
6 Likes
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.
13 Likes
- 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?
4 Likes
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!
1 Like
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.
5 Likes
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.
1 Like
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)
3 Likes
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
1 Like