The State of JavaScript on Android in 2015 is... poor

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 : . 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

1 Like

@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:


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:

  • using dirty checks instead of object.observe. This makes ember’s store really slow.
  • using css classes is slow, especially used at top-level
  • jquery events on a too broad scope
  • other things I can’t remember now, it’s in my todo list of stuff to document

Then I migrated to 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.


ember doesn’t seem load in safari - i had the same problem.

1 Like

I guess my question is: how big of a deal is this to actual Android users?

You’re comparing raw iOS numbers to Android numbers, and sure, they can be a little jarring.

But Android users aren’t sitting there holding an iPhone in one hand and their own phone in another. In other words, instead of comparing Android numbers to iOS numbers, maybe try comparing “Discourse on Android” numbers to “Other sites on Android” numbers. And not just numbers, but usability, etc.

I have a Galaxy Nexus, and only-okay internet usage comes with the territory of having an old device. Most websites are pretty slow. But I don’t also have an iPhone, so in a way I don’t know any better.

Discourse might be 5 times slower on Android compared to iOS, but it’s about the same speed (?) as other websites on the same device, and I think that’s the comparison most people actually care about. Apples and oranges, and all that.

I won’t say you’re making a mountain out of a molehill, but I do think maybe the people who live on the mountain don’t really mind that it takes them a little longer to get to the nearest Chipotle. Instead of worrying that people in the city can get to a Chipotle in 10 minutes instead of the hour it takes the mountain people, compare the time it takes the mountain people to get to the nearest McDonalds, because that’s the only comparison that matters to the mountain people.

Android users as mountain folk and Discourse as a Chipotle. I think that metaphor got away from me.

Edit: Whoops, I guess this is pretty much what @benfreke said. So, uh, what he said.


Just scored 236ms on my Note 5 using Next Browser. Looks like hardware isn’t the most important factor here.

Qualcomm Snapdragon series, Samsung Exynos series, I suppose Nvidia Tegra and standard ARM for the companies without an architecture license. That’s not that many, unless I misunderstood or I’m missing something. I just don’t think Google is trying all that hard to get Chrome high and tight. They seem to be depending on yearly faster hardware covering up the issues until they are fast enough for people to not complain.

with configurations i was referring to the fact that apple has a7,a7x a8,a8x i think and a few combinations with an extra core. But their designs are VERY homogeneous .

The situation with android (cpus):
Intel (x86)

They vary from 1 to 8 cores. Some designs are 2 big 2 small, some are 4 big, some are 4 small (ish).
That’s spanning several archictetures and bit sizes. They presumably require different optimizations - and google will have a hell of a hard time optimizing for all of them.
That’s not even getting into screen sizes, ram amount, storage speeds etc…
There are Several orders of magnitude more android configurations than there are iOS configurations.

I wonder what the benchmark looks like running in Intel’s Crosswalk. When I was attempting to deploy IonicFramework apps, it greatly improved the performance and consistency of our app. It made scrolling almost bearable.

Is that really true though? Most sites load a ridiculous amount of stuff, and a lot of it seems to rely on javascript. If javascript were turned off, the core content on the site might still load, but I don’t think most users disable javascript.

Therefore, it seems that benfrenke’s point still stands, with the qualification that the relevant benchmark for Discourse on android shouldn’t be Discourse on iOS, it’s a representative basket of websites on Android, many of which probably suffer with excess javascript “enhancements”

That’s a bit of backwards reasoning. With slow cores, and numerous ones, vs few high performing cores, you expect the same performance. Numerous slow cores will always be slower here. Just the work to switch from core to core, the way these processors are designed, wastes too many cycles.

Then there is the problem of four faster, more sophisticated cores, with four slower, less sophisticated cores. The processors were not designed for all of them to be working on the same problem at once. It’s a fundamental error in usage.

It is a combination of software and hardware. Based on the geekbench score, a galaxy s6 should be able to do close to as well as an iPhone 5s which has very similar geekbench single core score. You can see this in the AnandTech results I screenshotted when comparing the native browser and Chrome.

@tgxworld the benchmark runs fine in my very stock iPhone 6s under Mobile Safari. Maybe hard refresh?

1 Like