Hacker News new | ask | show | jobs
by spion 4722 days ago
Agreed. This analysis article [1] they refer to is overrated. Its almost as bad as the flame war articles that it criticizes mostly because it makes giant leaps of reasoning whenever that suits the author's point of view

For example, author answers the question "how does JS performance compare to native performance exactly?" by takinig a random benchmark from the benchmarks game. What I was hoping for was comparison with desktop browser in

  - dom manipulation
  - canvas
  - css animation performance
There are different problem domains, each requiring different kind of performance. The randomly picked benchmark is probably the one that is most removed from real world usage.

And from my personal experience, the worst performance bottlenecks in mobile JS apps are in DOM rendering and manipulation, not in raw JS speed. But my problem domain isn't games and image processing: instead it involves news reader, presentation editor, GPS tracking, tiled map rendering, exercise diary and stats app, and an app that makes Google Docs run on the iPad.

Interestingly enough, all iOS devices younger than iPhone 4 can do all of the above smoothly, even in a WebView where supposedly nitro is disabled, while the WebView on Android devices stutters and struggles to achieve 30 FPS, sometimes going down to 2-3 FPS even on modern devices and the latest version. So really, the raw JS performance already doesn't matter for my usage cases.

Its the variable rendering performance and behavior of Android's WebView that is the main problem. As soon as you think that you've found a solution to a certain rendering speed problem that works across all Android devices, a new version of Android appears on a certain device and invalidates that assumption by being slow as molasses in January.

Another example that makes it hard for me to take this article seriously:

"It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10"

How can he claim this with a straight face? Java itself is faster than Ruby by a factor of 10 - can he try to be a bit more accurate when making claims?

I agree with one statement of the article, however. "Let’s raise the level of discourse". However, this article doesn't do that at all.

[1]: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...
1 comments
rbehrends 4722 days ago
This really needs to be stressed more. I was underwhelmed by that article, too, because the author does not seem to have a deep understanding of the issues involved (specifically JIT compilation and automatic memory management) necessary. The overall conclusion -- that mobile HTML5 apps have inherent performance problems -- may well be correct, but not for the reason that he gives and for data that he often seems to misread.

The most glaring issue was probably the garbage collection performance graph: He picked out the performance of mark and sweep collectors to make a bold statement about memory usage necessary for performance, and completely ignored the data for the generational collectors for that statement.

This is not to say that garbage collection is a non-problem in mobile applications (it can be, but the argument for why is trickier and is not easily translated into soundbites), but somebody flat-out ignoring data does not inspire confidence.

The big problem is that the author doesn't ever seem to have seen a compiler from the inside, yet makes sweeping statements about programming language technology that simply aren't borne out by fact.

link