[williamcotton]

Ok dudes, enough is enough.

What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory?

All I see are some carefully selected quotes from some "hardware engineers" who are doing nothing more than offering up their opinion.

An "ex-Intel engineer" and a "robotics engineer" have a single paragraph. Really, this is your research? Some anonymous quotes, probably taken out of context?

> I have consulted many such qualified engineers for this article, and they have all declined to take the position on record. This suggests to me that the position is not any good.

Really.

Do I have to go on?

[anon1385]

>What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory?

Could you quote the part where the author of this article or the original Why mobile web apps are slow article say that we have reached a hard "limit of performance and memory", because I don't see where they say that at all.

The article I'm reading says this:

Unchecked exponential growth has to end sometime, by definition, and this is how it would happen; not with a bang, but with a whimper. We won’t hit a wall, we’ll just…start…to…slow…down.

[williamcotton]

Fine, I concede the point to you, however, I amend my question:

What actual proof does this dude have that performance and memory of pocket-sized computers have started to slow down?

And how does arguing this point have anything to do with his overall "thesis"?

Forest for the trees, man, forest for the trees...

[spion]

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

[rbehrends]

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.

[ippisl]

You're right.

There's a lot of interesting work on memristor memory, which is much cheaper and faster (and probably lower power) than RAM ,And a lot of interesting work on faster, lower power 3D memory interfaces.

Those and other hardware innovations could have a huge effect on the garbage collection issue, and this whole debate.

[poutine]

Agreed. If you look at the evidence we're doing quite well:

http://browser.primatelabs.com/ios-benchmarks

(The iPhone 5 is 2.5x faster than the 4S and 12x faster than the iPhone 1)