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

(Don Netzach) #147

This problem was very predictabel in 2013.

There is a strange expectation that mobile devices will follow the same path as desktop without considering the unque hardware constraints.

And for some period of time to come it most likely will get worse before it improves because the last few billion people on Earth without a smartphone will get a very low cost low performing device and represent a huge chunk of the user population.

In addition, for some time to come there is no breakthrough in battery technology on the near horizen and so no matter how many cores you add to the SOC, they will all throttle-down like crazy after the benchmark is over. Normal every day usage with some multi-tasking will actually show a worse user experience than a benchmark might suggest.

Apple has been in the unique position of innovating on a premium product for which the market realities of most of Planet Earth do not exist. The gap will widen at least until nobody is left that might buy a premium smartphone which has to happen at some point. All markets hit the end of the S-curve.

Presumably within 10-20 years there might be some sort of nano-tech battery breakthrough that will permit Moore’s Law to do its thing again…

(Kris) #148

We’re talking about the fastest android device being slower than the slowest iOS device. If you look at a more typical mid-range Android device (something with about the processing power of the iPhone 5), you’re looking at the difference between ~300ms and 1.5 seconds (at least). You’ll see a big difference in bounce rate simply based on those load times alone.

(Don Netzach) #149

Obviously lots of people run into this brick wall and go down the Native App road, which works.

Off the top of my head, there might be two ideas to consider.

  1. Transpile the JS to some more performant subset along the lines of ASM.js but without specific browser support there might not be a useful subset.

  2. Transpile the JS to C++ or Java to get a native app out of JS. Keeps a (mostly) common code base (since substitutes for dynamic code would be needed). Surely somebody has a product like this? (It would work like .NET Native in Windows 10)

(Allen Conway) #150

This is like someone making an argument that a 5.0 V8 Mustang is faster than a basic older mini-van. That’s a completely obvious statement. Junk will be junk and slow. Period. I think it’s more important to make strict comparisons between the elite Samsung devices (for example) and the iPhone products. Then the delta can be assessed, but my point was the delta might be over amplified in millisecond values compared to the real experience when comparing similar devices across platforms.

(Don Netzach) #151

But it’s not a race.

More like you’ve been asked to organize transport of medicine to earthquake victims and you have Mustangs and Mini-vans to work with and you ask your organizers for more Mustangs and what you will actually get allocated to you in the next few years is a shipment of golf carts.

(Allen Conway) #152

Ever notice in this analogy, the right device, hardware, car, etc. is picked for the job? In this same light, if it is a potentially life threatening situation, don’t plop code on a crappy Android tablet that was on sale at the local big box store for $69 last weekend.

I’ve worked in the medical industry and there is tight scrutiny and regulations around everything including hardware and risk analysis is always done. This would be determined ahead of time and have to be taken into consideration to avoid legal ramifications due to injury as a result.

(Henk Poley) #153

Yep, the next two years will be the fastest we’ll be adding people to the internet. Most of those will be on cheap mobile phones. No way these $50-$100 devices will be as fast as your shiny iPhone 6s, even in 2 years.

Nice graphs: On the future of the Internet and everything | Asymco

Compare scores of the low end SoC of the Lumia 550 (December 2015) with your high-end phone: Qualcomm Snapdragon 210 MSM8909 SoC Benchmarks and Specs - Tech

It gets 1/3 the Octane score of an iPhone 5S (September 2013). If x64 is any measure, Chakra will score an additional 2-3x worse than those Android benchmarks I linked to. And the Lumia 550 is even a 2-3x too expensive phone for a lot of non-westerners. Those cheap Firefox OS phones you keep hearing of, have the speed of the iPhone 2G/3G.

(ksec) #154


Its always hard to predict the future. But we can look at it this way, the last 50 years had moore’s law, the cost of transistor has been dropping price roughly every 24 months. We dont have that anymore, 28nm was the last one that bring the cost down.

So on the lower end of the spectrum, They could add better screen over time, battery or what so ever, may be better IPC etc but the performance increase will be very very slow over the next few years in the lower end sector. Not to mention the cost will likely shift to 4G, WiFi first. (
Display, 4G, WiFi Speed are much easier to sell and Market )
Oh, and if cost were allowed they will get more CPU performance 2 - 3 years down the road. Guess what we they do? Add another 2 Small core. Which in Discourse case doesn’t help.

Things will definitely improve over time. But dont expect the CPU performance to improve much in the lower end for the foreseeable future.

(Stephan Hoyer) #155

I am a developer and can’t only agree @Chad_J_Dupuis: Mithril will probably solve your performance problems. And it’s also very easy top learn and straight forward to use.

(Jeff Atwood) #156

We are about 2.5 years into a 10 year mission, so you would have to argue that in 5 years the situation would be identical. It is definitely true that Android JS perf has lagged massively behind iOS even in the last 2 years versus where I predicted they would be (closer to iOS, perhaps 1.5x slower, not 5x slower as it is now), so it is a question of whether that graph line shifts up or down or stays the same.

It is also encouraging that Apple is becoming so dominant, at least in first world countries, but I hope we have a better JS perf story in Android over the next 5 to 7 years, ideally in 2 years or less.

(Donny_V) #157

Option 1
Stop using 1 monolithic JS framework to do everything. Use RactiveJS for your UI and databinding. You could then run it on the server side using NodeJS and send Android users a pre-rendered view. Desktop and iOS users could get your full javascript powered version. Both versions would use the same code since your using NodeJS on the backend for Android users.

Ractive takes a different approach from Angular and other frameworks. Your template lives as a string, and is parsed (on the server, if needs be – Ractive is isomorphic) into a tree-like structure that can be transported as JSON. From there, Ractive constructs a lightweight parallel DOM containing all the information it needs to construct the real DOM and set up data-binding etc. In my view, this is a more hygienic approach. Parsing the template before the browser has a chance to has many benefits…

Option 2
Use asm.js. I don’t know the state of tooling for this but this could speed things up. But might make things a lot more complicated.

(Henk Poley) #158

RactiveJS is not particularly faster than Ember: <-- whoops, pretty old benchmark

It’s even slightly slower on Safari. Probably it’s different on Android, since in Chrome it’s a slight bit faster (2563ms / 3835ms). But if you could run a lot of it server side, that might help a lot. Actual fixes on the Android side will have to come from Chrome, so Ember is not hitting all these optimization/deoptimization cycles. Then some additional changes to make javascript multicore (hint: look at Erlang/Elixir). But that would be way more longterm.

asm.js in particular is much slower on any browser that does not specifically support it. That it “works” everywhere is the best thing you can say about it.

Mithril.js seems to be the fastest kid on the block currently. But I don’t know if that’s just because it doesn’t do very much.

(Srsgores) #159

What about for serving the app wIthout js? It’s free, open-source, and I believe there’s a Rails implementation.

As for me, I had no problems whatsoever using this site to post this very comment, and I’m on Android 5.1 on a note 3 (albeit overclocked to 2.5 Ghz, on custom kernel). I refreshed this page, and load times were very fast, under 1s. I think you may be exaggerating the problem.

(Henk Poley) #160

btw, not only is performance of Discourse poor on Android. If you load this page with a warm cache it takes 3.5 seconds before you have anything on the screen on a middle of the pack laptop from 2011 (i3-2310M) running Microsoft Edge (Win 10 build 10240). The average Windows computer was 4.4 years old back then. That number has probably only increased. So most people see worse numbers.

(Jeff Atwood) #161

Different issue; edge is literally no faster than ie11 in Ember. Try in Firefox or Chrome.

(Wes Osborn) #163

It seems that Google realizes they have a problem:

Unfortunately their solution does not sound optimal for Discourse:

Third-party JavaScript code, for example, has no place in the AMP environment.

Since their current performance problems seem to primarily lie with their platform “partners”, I’d agree that the possibility of “real” improvement in the near future is slim. They still haven’t managed to address the Android update problems that have plagued them for years.

(Robert Crockett) #164

We have a complex web app that is built on Backbone and Marionette. Our QA has not noticed any significant differences in how well it runs on Android vs iOS, except to say that iOS seems “smoother”, but not faster. Marionette provides a pretty good hierarchical structure for building a UI on the client and it is much lighter weight than Ember or Angular. However, compared to Angular the model binding is not nearly as good. I have not really used Angular, but I did research it to decide if we should switch to it.

I don’t have any idea how much of a rewrite it would be to switch to Marionette, but it might solve your problem without building the pages on the server.

(Donny_V) #165

That’s a ridiculously old version of RactiveJS. They’ve made a ton of performance updates since. Current stable version is .7.

(oblio) #166

Not entirely true. That security bug is for 2.2. Newer Android versions have a lot of core components decoupled from the base installation controlled by OEMs and carriers. Google has also tightened the Android requirements, giving them more control over Android.

Everything below 4.0 seems doomed, though, but the market share for those versions is rapidly declining.

(MattGow) #168

Certainly seem to be some promising things going on there. At around 23:30 (and elsewhere) there is talk of doing things in a way that V8 will handle more sensibly (fewer de-optimizations). The likely results are far beyond my skills to predict. Did anyone else get the sense that this might make an appreciable dent in the issue? Or are these kinds of improvements marginal at best?