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