I generally agree with his comments on JS and memory management, for stuff like games, or image processing, but IMHO, these are not, in general, the reason why

I generally agree with his comments on JS and memory management, for stuff like games, or image processing, but IMHO, these are not, in general, the reason why people have this notion that "mobile web apps are slow". There aren't a lot of games or Instagram apps written in JS, what there are, are lots of content oriented and form processing based mobile web sites, like your Bank, or your insurance company, or Slate or HuffingtonPost, and it is these sites which are prompting you to download native versions, and it is people's experience of these lightweight (non-CPU dependent) sites as being slow which I think needs addressing. I would break it down into three effects: 1) startup latency 2) excessive repaints/not leveraging compositor/jank 3) 'uncanny valley' issues where web emulations of native widgets don't match 100% with the feel of system widgets. The basic documented-oriented part of the mobile web is a lot slower than something like UIKit/TextKit in iOS, so the time to launch even a basic form to display some data, or a few paragraphs, and smoothly scroll it, with all rendering effects, and without layout or repaint jank, is just more work on the mobile web to optimize for, and therefore, many developers don't do it, or aren't aware of how to do it, leading to enduser perception that "mobile web is slow" I'd summarize my point of view as: NaCl/PNaCL won't solve our problems (although it is still a good idea to do them)