And with Perfect Browser and with Mobile Safari, on my Ipad Air. Android devices being slow is just half the story, the other half is that mobile devices have limited RAM and don’t page to disk.
Discourse is one of those web apps I have learned to avoid on my ipad because if I have too many tabs open, trying to load a forum that uses Discourse will crash my browser. That doesn’t happen on any other forums or commenting systems that I encounter on the web, just with Discourse.
Which iPad? If it is a 2010 iPad 1 with 256mb RAM, I’d expect crashes on lots of modern websites. If it is a 2012/2013 iPad 3 with 1GB RAM (or newer) you should be fine.
Modern iOS devices now finally have 2GB RAM (iPad Air 2, iPhone 6s) but I’ve never had any problems at all using Discourse for hours at a time on an iOS device with 1GB RAM.
Most modern-ish Android devices have 3GB or 2GB RAM. It does not help them much in the performance department, but it can help with paging out to disk.
For what it’s worth, I’m getting about 290ms on my OnePlus Two, so things aren’t quite as dire as the atrocious S6 might imply.
That’s encouraging. Slightly better than iPhone 5 – in which version of Chrome? Android did improve a bit in Chrome 44, 45, 46 in this area.
Tested on a fresh Chrome 45 install. big cores at work I suppose. 
I use Discourse almost exclusively on my Nexus 5. I find it quite usable. The performance seems fine to me, but maybe I don’t know any better. My main frustrations are with things not working quite right on mobile, e.g. quote reply.
I think it’s great that you’re taking performance so seriously though.
Try latest, or meta, I worked around a horrible bug 2 days ago
Though even post this change quoting is awkward I think a dedicated quoting mode would be a huge help on mobile
I’m very much in favour of this. A “Discourse Lite” isn’t just a workaround; it also broadens your userbase. The no-js and legacy phone users are a shrinking minority, but we’re still talking about millions of users here. It’s with good reason that Facebook offers a no-js interface for users like these.
(Anyone who wants to test this can go to Facebook with JavaScript disabled. They’ll give you the option to go to https://m.facebook.com. Will just redirect to desktop version if JS is on.)
This strategy can also be worked on in unison with “sticking to your guns” and powering onwards with Ember. I still have some faint hope in JavaScript on mobile. Looking at how prevalent Android is becoming as a platform, expanding from mobile phones to watches, laptops and TVs, and knowing how important an open web is to Google’s business, I can’t help but think things will get better. The same goes for Mozilla with their Firefox OS and “official support” for Ember.js as a top notch framework. I guess the bigger question is “when”. I find some solace in the fact that WebView is updated on my Android tablet almost daily.
Most of this has been covered above already, but I felt the need to collect my own thoughts about it, and I might as well make my musings public, however limited my point of view is.
The caveats of native apps are considerable:
Native apps don’t promote rainbows
Discourse forums are only just starting to differentiate themselves with unique fonts and colors, the baby steps of what will hopefully be a flourishing theme marketplace in the more distant future. Pushing native apps would hinder this trend, because why bother making your forum a unique-looking snowflake when a large percentage of your users are accessing it via a homogenized app anyways.
Discourse Plugins become very difficult to support
Niche plugins with functionality that falls outside of the scope of the native app would be rendered unusable, so there’d be less incentive to take Discourse off the beaten path with whacky experiments, which can be hugely detrimental to ongoing innovation.
Higher maintenance is still a factor
A framework like React does significantly lower the maintenance load (at least on paper - I’m no developer), but that native app you’re putting out is still a completely different beast with its own unique points of failure. Sure, developers gotta develop for different browsers already anyhow, but at least any effort in that area still contributes to WWW convergence in a sense, whereas developing for different native platforms is doing favours for no one besides the respective platforms.
Conclusion: The native app strategy works far better for centralised platforms
If you’re Facebook, React makes a ton of sense. Everything is under your control, you have an established native app story out there already and the room for customisation of a user’s own space is very limited and predictable.
Could the equivalent of a Reddit BaconReader for Discourse forums still be a breakout success? Absolutely. But I’d rather leave that risk&reward free for the taking by another talented bunch of individuals, just not the core Discourse team.
Oooo, it works!!! Thanks!!! 
I’m not sure what speed my Galaxay S4 gets, but I honestly hardly notice any real slowness, sure the initial load isn’t instant, but it is like I have to set my phone down and wait either. If you go the route of defining “older mobiles as non-js”, I would like a way to force it into JS mode, as most of the time, I visit via mobile out of necessity, not desire, and part of the necessity is being able to reply or act on a give topic/post.
This is mostly due to the lower acceptance of JavaScript and JS Frameworks in the Japanese - Korean hemisphere. In fact they are going to have first Angular conference this year : http://ngjapan.org/ . I guess this just influences the management and engineering team over there to not to concentrate on optimizing JavaScript. JavaScript scene is very weak in Eastern Hemisphere.
As Jeff shows, its not a problem of android, but a problem of the JavaScript language not supporting proper multicore support.
Isn’t a JS website app also a “lower common denominator solution” when compared to native apps?
If the issue is that android devices improvement focus on multithreading, using web workers could help.
me? ipad air 1 as stated above.
[quote=“sam, post:68, topic:33889”]
Try latest, or meta, I worked around a horrible bug 2 days ago
[/quote] it’s still weird on the ipad.
I can select, but the iOS menu “copy/select/…” pops up above/on top of the quote reply button.
Point of clarification: we know the performance gap comes down to the software, not the hardware. Chrome on desktop is much slower than Safari on desktop, on the same hardware. (People just care less about the gap on desktop, because both are “fast enough”.)
After much deep-diving into V8 internals, I am convinced it is because V8’s optimizing JIT compiler is way too aggressive. It constantly attempts optimizations that turn out to be bad and need to be backed out. Basically, V8 gambles hard on optimizations: if they turn out to be right, it is blazingly fast. If they turn out to be wrong, it’s worse than not trying to optimize at all.
This is why you will often see “(compiled code)” as the number 1 thing getting garbage collected in an Ember app on Chrome. V8 is constantly compiling functions, discovering they are overspecialized, and throwing them away.
You are actually describing a Microsoft tactic. As far as the user is concerned, the site IS at fault. It’s just that some of us know it’s an Android hardware deficiency. Let’s not tell them, since then they would only go to iOS like everyone else with a clue in this game. Once they get in iOS and realize all the lies they’ve been told about it are wrong, they will be just like a Mac user moving from Windows–they will NEVER give up the Apple gear. LOL
@codinghorror What browsers did you run the benchmarks for the Apple devices on? I’m on a iPhone 6 Plus and I can’t run the benchmarks on safari. It just won’t start. On chrome 45, I got the following results:
Hi,
just saw the tweet, I thought I could share my experience when it comes to chrome on android. Just to show how far I went I’m making this html5 midi controller DJ Crontab: Building a HTML5 Control Surface for Ableton Live , part 1 ; didn’t have the time to document the javascript part yet. I acknowledge my problem is of a different nature: it’s not content, I’m not targetting low-end devices at all, I don’t care about compatibility.
My first attempt was using emberjs, and this was ridiculously slow. Weak spots I could find:
Then I migrated to aurelia.io which uses latest chrome capabilities, and a lot of custom code to allow fast repaint ( object.observe, canvas, webworkers, directly handle events myself instead of wrapping it with jquery, etc. ), and then I could get something that can be used for the purpose of realtime control.
But then again I don’t have any compatibility constraint and I don’t need content helpers. aurelia is very light on features and documentation so far, but proves javascript can be faster when using latest features, which are available on any android devices ( in contrast to, say, someone stuck with IE8 ). But, since you want to make a bold move due to android’s sluggishness, you should consider dropping ember. The way it’s designed, I’m not sure they will implement latest javascript features anytime soon.
So, it’s hard choices, I’m not in your shoes, but I’m pretty sure a dedicated android application is not the best investment, and that you should try harder to either fix or start from scratch the web application with a better foundation.
Ok… So we are comparing performance of JavaScript on two dissimilar devices… In two different browsers (article does not states this btw). What is the control here? Is this like comparing a propeller plane and a fighter jets taxi speeds? I feel like the real test that needs to be done is to compile nodejs and run the tests for both devices. I am getting this uneasy cheating feeling from safari… And before you say “they would never”… I point out VW. As someone who has used Safari on iOS (who hasnt) I would not classify it as a blown away fast experience. In no way is it 4x as fast as chrome on Android like these numbers suggest. Something is off here. I would expect them to be similar… Not off by multiples.
