Tech The State of JavaScript on Android in 2015 is… poor

[Denny Crane]

https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889

codinghorror Jeff Atwood co-founder

For several years now we've tracked the fact that, over time from 2012 onward, Android JavaScript performance has become wildly divergent from iOS JavaScript performance. And not in a good way.

To give you an idea of how divergent it has become, try:

• http://emberperf.eviltrout.com
• Complex list
• Ember 1.11

This is the benchmark most representative of Discourse performance, and the absolute best known Android score for this benchmark is right at ~400ms on a Samsung Galaxy S6. That doesn't seem too bad until you compare..

• iPhone 5 → 340ms
• iPhone 5s → 175ms
• iPhone 6 → 140ms
• iPad Air 2 → 120ms
• iPhone 6s → 60-70ms

In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing.

We've done enough research to know this issue is not really specific to Ember, but also affects Angular andmost other heavy/complex JavaScript on Android. Why?

Part of it is indeed Chrome/V8 JavaScript optimization issues on Android as you can see from this AnandTech Galaxy S6 review. Note the browser used:





It's also partly because single core performance on Android is falling way, way behind iOS. Notice that the flagship Android device barely has the single core grunt of an old iPad Mini based on the old A7 core. Compare single core Android GeekBench versus single core iOS GeekBench:



It seems the Android manufacturers are more interested in slapping n slow CPU cores on a die than they are in producing very fast CPU cores. And this is quite punishing when it comes to JavaScript.

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.

I am no longer optimistic this will change in the next two years, and there are untold millions of slow Android devices out there, so we need to start considering alternatives for the Discourse project.

 

[HailBlazers]

Damn, love my HTC but hate that my wife's Iphone 6 is faster and gets better service on the same carrier.

 

[andalusian]

This is an interesting read, but to be fair, the biggest things in ES6 seem to be workers, generators and promises which really shows you that the Javascript world at large (not just mobile, but also desktop and server) is really trying to move away from single-core computing to concurrent computing. I am going to say that it seems to me that this is much less of an issue than he is trying to make it to be.

I know that we use clusters in our node server code to take advantage of multiple cores, we use workers on our client code anytime there are long computations that you need to perform at the JS level - who really needs to perform such massive computations on the client in single-threads anyway? Advanced graphics is mostly going to the GPUs that are massively parallel anyway, workers should be able to break whatever large jobs you have into multiple threads - but quite often, when you really need to do these large computations you just throw things to the cloud and run them on much faster servers anyway. It is not like you have giant databases locally on the mobile device that require that much speed in single core execution.

What applications are really needed on mobile that require desktop level single-core performance?

Do not get me wrong - I think it is super-impressive how fast the iPhone 6S is even compared to the iPhone 6 - these guys are doing amazing job with their CPU design - but I am just not sure that single-core Javascript performance is that big of a deal in the mobile world.

 

[Denny Crane]

I don't think you can excuse away Android's poor JavaScript performance.

That post is by one of the foremost JavaScript experts.

JavaScript is single threaded, and there is not anywhere enough in terms of applications that use worker threads and the like.

People do things like filter/map/reduce in JavaScript on arrays of items (like forum threads) that do take time to execute and compose in JavaScript. Anyone who uses a JavaScript heavy application, including using any of the popular frameworks (AngularJS, React, etc.) is going to suffer poorer user experience due to the JS engine performance.

The issue isn't massive computation or rendering, it's simply using jQuery to select a bunch of elements by selector and adding a class to them - the JavaScript performance matters a LOT.

 

[andalusian]

I don't think you can excuse away Android's poor JavaScript performance.

That post is by one of the foremost JavaScript experts.

JavaScript is single threaded, and there is not anywhere enough in terms of applications that use worker threads and the like.

People do things like filter/map/reduce in JavaScript on arrays of items (like forum threads) that do take time to execute and compose in JavaScript. Anyone who uses a JavaScript heavy application, including using any of the popular frameworks (AngularJS, React, etc.) is going to suffer poorer user experience due to the JS engine performance.

The issue isn't massive computation or rendering, it's simply using jQuery to select a bunch of elements by selector and adding a class to them - the JavaScript performance matters a LOT.

Javascript in it's ES5 incarnation (came out in 2009) is single threaded, but as I pointed out - ES6 (the new generation of Javascript that the spec just released in June 2015) is heavily into multi-threading via workers, promises and generators. Javascript, as a language, seems to bet big on multi-core support.

All new Javascript engines are slowly getting more and more ES6 features. This is the new Javascript. This is where the world of Javascript seems to be going. You will see more and more engines support it and more and more libraries updated to take advantage of it.

Honestly - we write a lot of Javascript. Using jQuery or whatever library you want to query a large DOM structure and add a class to it is a milliseconds operation - no-one is going to see the difference between a 20ms or 80ms operation. There is no reasonable difference between these. Our KendoUI app UI is just as snappy on my old Nexus 7 from 2013 (which is really slow compared to modern phones) as it is on an iPhone 6 - I am certain it runs a lot faster on the iPhone 6 - you just can not feel it, this is not large enough a dataset for the single-thread performance to really see a difference.

There is one forum that does not support Tapatalk that I read with that same Nexus 7 directly - and it is super-fast (actually much faster than Tapatalk, I should really check S2 directly in the browser there as well) - the computation speeds are fast enough for these operations for user perception.

I do have a side-project that does Non-Photo-Realistic rendering in Javascript where I have really large datasets and the code does not fall into the normal GPU processing patterns for graphic programming - that is where you can see how slow single-core JS is on my old Nexus 7. But, if I break my dataset to run on 3 concurrent workers (with one core for the master) - it is a reasonable wait time for a complicated, cpu heavy operation. Granted, it is faster on the iPhone 6 (and should be even more so on the iPhone 6S) - but my Nexus 7 is 3 generation old as far as a CPU is and runs 32 bit. I am certain that if were to run this code on an Octa-core 64bit processor like the latest Samsung device (I can't stand Samsung's WizTouch so I will not purchase one, but this is a different discussion) - it will be just as fast if not faster than the code on the iPhone.

With that said - what Apple has done is basically made it much easier to write good performing JS code on their processor - and that's very impressive and very smart - you have to work hard to write bad performing Javascript software on the Apple, where it is much easier to write bad performance JS software on devices that are not optimized for single-core performance.

It is always easier to write simple, single-threaded code and have it run fast. It is just that I am not certain how much of an issue it really is in the mobile world - because I still do not think that there is really that much need / real-world application for desktop class single-core javascript applications on mobile devices.

 

[Denny Crane]

I write ES5 and ES6 all day for my living.

JavaScript is single threaded.

People absolutely notice the slow performance.

You are arguing against Jeff Atwood, who founded Stack Overflow, Stack Exchange, and WikiPedia. I know he's right.

Damn, love my HTC but hate that my wife's Iphone 6 is faster and gets better service on the same carrier.

 

[Denny Crane]

BTW, I visit S2 on my Galaxy Tab 4, and when I click on a link to view a thread, the screen goes blank for seconds and then the whole page appears.

It's really slow.

 

[andalusian]

BTW, I visit S2 on my Galaxy Tab 4, and when I click on a link to view a thread, the screen goes blank for seconds and then the whole page appears.

It's really slow.

I just moved to my old nexus 7 and writing from it, it is all snappy and good. This could very much be an issue with the Samsung.

 

[Denny Crane]

I just moved to my old nexus 7 and writing from it, it is all snappy and good. This could very much be an issue with the Samsung.

Read carefully. Doesn't mention specific to Samsung. Say's Android.

In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing.

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. Why?

Part of it is indeed Chrome/V8 JavaScript optimization issues on Android

 

[andalusian]

I write ES5 and ES6 all day for my living.

JavaScript is single threaded.

People absolutely notice the slow performance.

You are arguing against Jeff Atwood, who founded Stack Overflow, Stack Exchange, and WikiPedia. I know he's right.

I write Javascript for a living too - and honestly, most of my work is not single-threaded anymore. Maybe because I did so much work on Node where everything is async - but we use promises, clusters, workers - everything to run things concurrently all the time.

I am also not arguing that Javascript single-core is not slower on Android devices - it is - what I do argue is that I am yet to hear of a real-world application where it is really that important. S2 is fast and responsive on my antique Android device. DOM manipulation needs to be really stupid to be slow on it - it is really not an issue I can feel with S2, our own software or other things I do in the browser.

Jakob Nielsen in "usability engineering" has 3 "classes" for perceived performance - anything less than 0.1 second (100ms) feels feel instantaneous, anything up to 1 second is generally OK, but the user will feel the pause and finally, if an operation takes 10 seconds or more to complete, you’ll struggle to maintain the user’s attention.

I just ran an interesting test, on that Nexus 7 I cleared the cache - and over my 801n wifi connection went to CNN.com - a heavy web page with a lot of images, it took from scratch until it finished 2.5 seconds and that included all the network communication - which you know is likely to be an order of magnitude larger than whatever CPU is needed to make it nice and responsive.

I ran the exact same scenario on my desktop with the Chrome Dev Tools - it was almost 2 seconds of network (and this machine is not on wifi - so likely faster).

This leads me to believe that the Javascript on this page is well below the 1 second portion of the performance - quite frankly, someone has to write really bad DOM manipulation for it to be a real issue in most applications.

Read carefully. Doesn't mention specific to Samsung. Say's Android.

I was answering specifically about S2 on the Samsung. The Nexus 7 is running Lollipop with the latest Chrome build - and S2 is snappy on it. Again, not arguing that Javascript single-core performance is great on Android, it is clearly not, the benchmarks show it so. I just do not think it is that much of an issue in the real world.

 

[MarAzul]

People absolutely notice the slow performance.

Ha! Funny to see that said. On the other side of the issue, people do not notice faster performance, if it was already fast enough for people not to perceive a delay. Come to think of it, slower is ok too if it is still fast enough.

 

[Denny Crane]

I write Javascript for a living too - and honestly, most of my work is not single-threaded anymore. Maybe because I did so much work on Node where everything is async - but we use promises, clusters, workers - everything to run things concurrently all the time.

I am also not arguing that Javascript single-core is not slower on Android devices - it is - what I do argue is that I am yet to hear of a real-world application where it is really that important. S2 is fast and responsive on my antique Android device. DOM manipulation needs to be really stupid to be slow on it - it is really not an issue I can feel with S2, our own software or other things I do in the browser.

Jakob Nielsen in "usability engineering" has 3 "classes" for perceived performance - anything less than 0.1 second (100ms) feels feel instantaneous, anything up to 1 second is generally OK, but the user will feel the pause and finally, if an operation takes 10 seconds or more to complete, you’ll struggle to maintain the user’s attention.

I just ran an interesting test, on that Nexus 7 I cleared the cache - and over my 801n wifi connection went to CNN.com - a heavy web page with a lot of images, it took from scratch until it finished 2.5 seconds and that included all the network communication - which you know is likely to be an order of magnitude larger than whatever CPU is needed to make it nice and responsive.

I ran the exact same scenario on my desktop with the Chrome Dev Tools - it was almost 2 seconds of network (and this machine is not on wifi - so likely faster).

This leads me to believe that the Javascript on this page is well below the 1 second portion of the performance - quite frankly, someone has to write really bad DOM manipulation for it to be a real issue in most applications.



I was answering specifically about S2 on the Samsung. The Nexus 7 is running Lollipop with the latest Chrome build - and S2 is snappy on it. Again, not arguing that Javascript single-core performance is great on Android, it is clearly not, the benchmarks show it so. I just do not think it is that much of an issue in the real world.

In a company of 50+ JavaScript developers, nobody here wants to work on android because it sucks.

Read carefully.

In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing.

We've done enough research to know this issue is not really specific to Ember, but also affects Angular andmost other heavy/complex JavaScript on Android. Why?

Part of it is indeed Chrome/V8 JavaScript optimization issues on Android

AND

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.

 

[MarAzul]

So, why isn't this the end of Android?

 

[Denny Crane]

Another post by Atwood from 2014. > 1 second and closer to 1.5-2 seconds for Galaxy and Nexus devices. Measured not by the sphincter test, but accurately in milliseconds. We're not talking your 100ms perception kinds of values here.

http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-android/6577

One thing we have struggled with for a year at Discourse is how slow Ember is on Android devices. How slow? See for yourself:

Ember 1.8, Complex List test: http://samsaffron.github.io/ember-performance/?ember=1.8.0672

iPad Air 2 -- 224 ms
iPhone 6+ -- 252 ms
iPhone 5s -- 300 ms
iPhone 5 -- 600 ms
iPhone 4 -- 2031 ms
Galaxy S5 -- 1297 ms
Nexus 5 -- 1426 ms
Nexus 7 -- 1930 ms

Surface Pro 3 Core i5
IE 11 (x64, touch) -- 613 ms
Firefox latest -- 312 ms
Chrome latest -- 260 ms

Desktop Core i7-4470k
IE 11 x32 -- 390 ms
Firefox -- 245 ms
Chrome -- 181 ms

Intel Bay Trail Atom Asus T100 1.33 Ghz Z3740 IE 11 (x64, touch) -- 2.2 sec
Firefox latest -- 1.6 sec
Chrome latest -- 1.2 sec

There is a year old bug open in Android Chromium on this..
https://code.google.com/p/v8/issues/detail?id=2935333

I had some hope that Android 5 / L would fix this somehow as the old creaky Dalvik was replaced with native code. But people have replied with preliminary Lollipop results and they look no better, so I am no longer optimistic. I do have a Nexus 9 ordered, which is as good as it gets for the forseeable future, and I will report in when that arrives.

It's been a year now since we originally observed the problem. Ember performance is great on iOS and laptop and desktop, and improves every year as hardware gets faster... but horrendously bad 3x - 5x slower Ember Android performance, for better or worse, seems to be the long term status quo. Is there anything Ember can do to help address it? Either by nudging people at Google or identifying exactly why the very same Javascript is so incredibly slow on every Android device?

 

[Denny Crane]

So, why isn't this the end of Android?

Apple is kicking android's ass lately.

http://bgr.com/2015/05/18/iphone-6-vs-samsung-android-sales/


Samsung’s iPhone nightmare is far from over, and now it’s affecting Google

and

http://bgr.com/2015/01/29/tim-cook-iphone-6-vs-android/

You might think of iPhone owners as an insular crowd, constantly upgrading from one device to the next, year after year, but Tim Cook says that’s not the case. In an interview with The Wall Street Journal, Cook said that fewer than 15% of iPhone 6 and 6 Plus sales came from customers upgrading from another iPhone.

(which means they're upgrading from android phones)

 

[MarAzul]

Maybe I will be forced someday. But right now a netTalk and Tracphone work for me.

 

[Denny Crane]

I'm pretty sure everyone who upgraded from an iPhone 4 to an iPhone 5 noticed how much faster everything worked.

I'm pretty sure everyone who upgraded to the iPhone 6 also notices the speed increase.

Hard disk is plenty fast. Next to an SSD, it's dog slow.

 

[HailBlazers]

I write Javascript for a living too - and honestly, most of my work is not single-threaded anymore. Maybe because I did so much work on Node where everything is async - but we use promises, clusters, workers - everything to run things concurrently all the time.

Wanna move (back?) to Portland?

 

[andalusian]

Wanna move (back?) to Portland?

Loved everything about Portland other than the weather, but I can not see myself coming back - as much as I loved everything else there - we are just loving it down in the San Diego area.

There are things that are not as nice as Portland and it was hard to leave friends behind - but honestly, I think that I enjoy San Diego more. Portland will always have a special place in my heart - and I am ready to come back for a visit - but that's about as much as I can take the rain.

 

[JfizzleBlazer]

Lol why is everyone still having a Samsung vs iPhone debate? Hint. They both suck after. A couple years. My wife has stuck with iPhones and I've always been android so I've been able to see both sides of the table. Honestly I stay away from Samsung and apple. Give me a nexus stock android any day of the week over a Samsung.

Tbh the rumored HTC one m10 is going to destroy apple and Samsung spec wise. That's the one I'll be waiting for.

 

[Denny Crane]

This isn't a iPhone vs Samsung "debate."

It's the founder of three of the most popular technology sites ragging on poor Google Chrome performance on mobile devices.

 

[andalusian]

This isn't a iPhone vs Samsung "debate."

It's the founder of three of the most popular technology sites ragging on poor Google Chrome performance on mobile devices.

It really isn't the case. This is a single-core performance. The A9 (latest iPhone cpu) has 2 very powerful cores. Most modern Android phones run CPUs with 4 to 8 smaller, less powerful cores.

While the A9 is faster overall than anything currently out from Qualcomm (the 810) and slightly faster than the latest Samsung chip in the S6 Edge - the overall performance gap is not gigantic. Any comparison that compares single-core performance on a machine with only 2 "big and fast" cores to single-core performance on a machine that has multiple smaller cores is really comparing apples to oranges.

Software needs to be written to the architecture it runs on to be optimized - and good Javascript apps on Android should be written to take advantage of the multiple cores properly.

All you need to do is forget about Javascript for a second and compare overall chip benchmarks - Take something that has a single-core and multi-core tests like Geekbench,

If you look at single-core performance, the A9 scores 2484 on the iPhone 6S compared to a single core score of 1316 for the Samsung chip in the S6 edge. Clearly, it has 2 very fast cores where the Samsung has 8 smaller, not as fast cores. Is it a surprise that single-core performance of anything on such separate architectures will benefit the chip with fewer, faster cores? FWIW - if you look at the multi-core Geekbench benchmark for these 2 same chips, the Samsung scores 4404, the iPhone scores 4403.

This is like looking at a V8 engine and a 4 cylinder engine of similar displacement and claiming that the 4 cylinder is better because it produces more power from each cylinder. The people that define the Javascript standard recognized that the world at large goes multi-core - on desktops, servers and even mobile - and Javascript is going that way with all the new stuff we see in the newer versions of it. Until the software world catches up and redesigns to work properly with this architecture - there will be an advantage to running Javascript apps on bigger, faster cores - but once the software is updated to use multiple core properly - this is no longer an issue.

I still contend that while it is clear that Google has some work to do on single-core performance in V8 (*) on mobile - in real world applications on mobile - this is a distinction without true benefit.

(*) - Isn't it nice how Google called their Javascript engine V8 to work well with my metaphor?

 

[EL PRESIDENTE]

I PREFER THE $400 I SAVED IN MY POCKET THAN THE SPEED I'M NOT MISSING

 

[Denny Crane]

It really isn't the case. This is a single-core performance. The A9 (latest iPhone cpu) has 2 very powerful cores. Most modern Android phones run CPUs with 4 to 8 smaller, less powerful cores.

While the A9 is faster overall than anything currently out from Qualcomm (the 810) and slightly faster than the latest Samsung chip in the S6 Edge - the overall performance gap is not gigantic. Any comparison that compares single-core performance on a machine with only 2 "big and fast" cores to single-core performance on a machine that has multiple smaller cores is really comparing apples to oranges.

Software needs to be written to the architecture it runs on to be optimized - and good Javascript apps on Android should be written to take advantage of the multiple cores properly.

All you need to do is forget about Javascript for a second and compare overall chip benchmarks - Take something that has a single-core and multi-core tests like Geekbench,

If you look at single-core performance, the A9 scores 2484 on the iPhone 6S compared to a single core score of 1316 for the Samsung chip in the S6 edge. Clearly, it has 2 very fast cores where the Samsung has 8 smaller, not as fast cores. Is it a surprise that single-core performance of anything on such separate architectures will benefit the chip with fewer, faster cores? FWIW - if you look at the multi-core Geekbench benchmark for these 2 same chips, the Samsung scores 4404, the iPhone scores 4403.

This is like looking at a V8 engine and a 4 cylinder engine of similar displacement and claiming that the 4 cylinder is better because it produces more power from each cylinder. The people that define the Javascript standard recognized that the world at large goes multi-core - on desktops, servers and even mobile - and Javascript is going that way with all the new stuff we see in the newer versions of it. Until the software world catches up and redesigns to work properly with this architecture - there will be an advantage to running Javascript apps on bigger, faster cores - but once the software is updated to use multiple core properly - this is no longer an issue.

I still contend that while it is clear that Google has some work to do on single-core performance in V8 (*) on mobile - in real world applications on mobile - this is a distinction without true benefit.

(*) - Isn't it nice how Google called their Javascript engine V8 to work well with my metaphor?

Blah blah "written properly."

The fact is JavaScript is single threaded, only uses one core for the vast majority of applications, and hybrid apps using "modern" frameworks are all going to use one slower core in a less optimal JavaScript engine. Hybrid apps are appealing because one code base runs on iOS and Android (and Windows...).

No, the world is not moving to multi threaded JavaScript. They're moving away from it. TraceMonkey had badly working multithreading, but Mozilla ripped that code out altogether. Oracle ditched Rhino, which fully supports native threads in the JVM in support of Nashorn, which isn't JVM thread safe.

Web Workers are not threads. They are isolated. Processes, at worst.

What the world is doing is moving more logic to the server side. See Silk browser, for an example.

Even worse, the browser rendering engine and JavaScript engine run in the same thread. The JavaScript code does not run while rendering is going on, and rendering does not happen if JavaScript code is running.

Single threaded.

Multiple cores does allow multiple programs to run at the same time. Native apps can use real threads and all the cores.

 

[Denny Crane]

The blah blah bit wasn't to be rude.

You are arguing with the guy who founded stack exchange and wikipedia. I'm quite certain he knows what he's talking about, his assessments are sound, his complaint is valid, his ability to craft software the "right way" is second to none, etc.

NodeJS is written on top of V8, the js engine in Chrome. If your server app throws an error, the whol thing goes bye bye. Because it is not multithreaded. Even cluster isn't a good solution. In production, people run 4x server instances on a quad core server or vm.

 

[andalusian]

The blah blah bit wasn't to be rude.

You are arguing with the guy who founded stack exchange and wikipedia. I'm quite certain he knows what he's talking about, his assessments are sound, his complaint is valid, his ability to craft software the "right way" is second to none, etc.

NodeJS is written on top of V8, the js engine in Chrome. If your server app throws an error, the whol thing goes bye bye. Because it is not multithreaded. Even cluster isn't a good solution. In production, people run 4x server instances on a quad core server or vm.

I am not arguing with what he said technically, I am arguing that there is no real application he (or you) showed that required this single-core JS application on mobile. Just because he is correct technically - does not mean it matters much if there is no real-world benefit for it. Apple for example is correct in keeping their screens at resolutions with lesser PPI than latest Android screens - because the difference is imperceptible for the human eye. Likewise, until I see real world Javascript applications that require this kind of single-core performance - it is technically correct while providing no real world impact.

Let's face it, the vast majority of Apps on both Android and iOS are not written in Javascript - and I just do not know of that many close to the metal Javascript apps anyway - for 99% of the use cases - this is really a non-issue.

As for what is happening with our NodeJS code - I can assure you that a simple event handler to catch unhandled errors takes care of 99.9% of all issues that were not handled elsewhere. The amount of time we needed to have unscheduled restart of the code can be counted on one hand for over 2 years of operation - and at least a couple of these issues were related to AMI issues and not our code.

As for clusters in Node - they are far from perfect - but they are definitely more efficient for our App that running multiple processes of the same server - and we benchmarked the hell out of it. But, like everything else, Node was quite early in Clustering support and while it is far from perfect - it became a lot better in v0.12 - not that it matters too much as we did our own master to worker routing almost from the start to overcome Node's built in inefficiencies.

 

[andalusian]

Even worse, the browser rendering engine and JavaScript engine run in the same thread. The JavaScript code does not run while rendering is going on, and rendering does not happen if JavaScript code is running.

And that's why you move that code to workers. I write a lot of long imaging code that runs in separate workers to speed operations and not tie the UI to the operations. It is a pretty common practice to capture the image-data from the canvas, pass it to a worker or two and let them do their thing without stopping the UI. You have just given the classic example of why running multiple threads/workers/processes is required.

 

[Denny Crane]

I am not arguing with what he said technically, I am arguing that there is no real application he (or you) showed that required this single-core JS application on mobile. Just because he is correct technically - does not mean it matters much if there is no real-world benefit for it. Apple for example is correct in keeping their screens at resolutions with lesser PPI than latest Android screens - because the difference is imperceptible for the human eye. Likewise, until I see real world Javascript applications that require this kind of single-core performance - it is technically correct while providing no real world impact.

Let's face it, the vast majority of Apps on both Android and iOS are not written in Javascript - and I just do not know of that many close to the metal Javascript apps anyway - for 99% of the use cases - this is really a non-issue.

As for what is happening with our NodeJS code - I can assure you that a simple event handler to catch unhandled errors takes care of 99.9% of all issues that were not handled elsewhere. The amount of time we needed to have unscheduled restart of the code can be counted on one hand for over 2 years of operation - and at least a couple of these issues were related to AMI issues and not our code.

As for clusters in Node - they are far from perfect - but they are definitely more efficient for our App that running multiple processes of the same server - and we benchmarked the hell out of it. But, like everything else, Node was quite early in Clustering support and while it is far from perfect - it became a lot better in v0.12 - not that it matters too much as we did our own master to worker routing almost from the start to overcome Node's built in inefficiencies.

NodeJS servers crash.

They invented programs for servers to assure NodeJS is running and starts a new server if the active one crashes.

Their philosophy is that if your program throws an uncaught exception, you have a serious enough error that your program is hosed.


Again, you're arguing with the guy who made stack exchange and wikipedia who thinks the state of JavaScript on android is awful.

Not native apps, not machine language, not server applications. JavaScript.

Why? Because he, like gazillions of other companies and developers, want to run JavaScript hybrid apps for their portability, robustness, and cost savings and ability to even share code between server and application.

Thread title:


EDIT: