[JackdawX]

This is a post responding to the following article that was posted on HN yesterday-ish: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

The point of that article was to specifically call out lazy surface-level discussions of HTML5/js apps by throwing out some benchmarks, and trying to have a practical fact-based discussion. I found the article very convincing actually, and what I wanted to see was both browser-app proponents and detractors testing out the limits of what the browser is capable of, so we can determine what is and is not viable to program in the browser stack.

This piece is simply not an answer to that article in any way. It does not attempt to answer the question posed in the title, nor does it address any of the points of it's parent article. I think we need to step up the level of discussion here if we want browser tech to be more viable for general use.

[williamcotton]

Oh, but it does step up the level of discussion, because there are more important matters involved than mere performance gains. Also, the author of yesterday's article pinned a good deal of his "thesis" on some hand waving about how pocket-sized computers won't increase in performance and memory. He stated that ARM is incapable of keeping up with Moore's Law and will have to be replaced by x86. His statements about the likelihood of vendors being capable of shipping hardware that continues to improve is based on nothing but his opinion. It is not in any way supported by some cursory emails with hardware engineers. The MHz limit has nothing to do with Moore's Law, it merely pushes us Ina multi ore direction... So lets say we have 80 cores... Well, one javascript run time could potentially use an entire core! Also, his one engineer quote admits to having an 'incredibly biased opinion'. Really guys, this kind of stuff is what convinces you?

The reason a veteran like Dan take issue with the hardware and performance side of things is that is what originally held back dynamic interpreted languages in the first place. There were a zillion arguments about how Smalltalk and Lisp were just too damn slow and would never be capable of the performance present in languages closer to the metal. Thought the 90s and the 00s these opinions were clearly rendered moot.

Also, lets think about where are problems are actually bound. With games, 3D rendering and graphics are a big pain point and developers spend a lot of resources to cordon off and optimize this code. And then they frequently use a language like Lua to do everything else. This is basically the approach of APIs like WebGL.

[dgreensp]

The way I see it, if you look at the iPhone as a slightly faster IE8 plus a graphics card (plus string concatenation that doesn't memcpy and probably various other asymptotic or order-of-magnitude improvements in specific areas), you can do a lot with that. You can perfectly well argue about the less-well-supported facts and opinions in the original article that are used to interpret the performance facts.

For example, the anecdote about Wave that's supposed to demonstrate you can't do realtime collaboration on IE8. Well, I worked on Wave at Google (briefly) and it's no such proof. I also wrote EtherPad, which was realtime collaborative in IE6. You can't disqualify arguments of the type "I wrote an app one time" and then talk about the impossibility of writing apps.

The matter of whether phones will get yet faster is another great question, and one I'm not qualified to comment on, but I wouldn't bet against it.

I totally get the part about GC in a memory-constrained environment, photos, and the iPad's giant screen. However, the author of the original article doesn't stop before making many broad, indefensible claims.