Most of these don't seem like "myths" so much as "uncomfortable realities". It's not a myth that native apps are faster because they get preferential access to the hardware, for instance, it's just a fact.
Interesting, when I look at the given "Things HTML5 can do that native Apps can not", I notice that those things are important to developers, not to the end users.<p>End users do not care about "write once deploy everywhere". But they do care about the responsiveness, battery life, native look and feel, etc<p>So far HTML5 apps are following the trajectory of "Java on a desktop".
This article does not seem to be objective and honest. Yes you can monetize an HTML5 app, but there is a difference between can monetize and can monetize and actually make money.<p>If you are going to criticize app stores, you might want to factor in the reality that Apple has paid out over 6 billion dollars to app developers. The article mentions phone gap, that's true, so that's fine, but I'm addressing the point about monetizing on the web.<p>This article also is cherry picking news articles. It picks the Financial Time's article but doesn't mention Facebook's switch to native.<p>The build once, run everywhere point is flawed as we know that you actually do have to test and add various fixes here and there and worry about screen size, poor development environments on mobile and the like. You also do not have to write the vast majority of your app more than once for multiple platforms. I know a featured developer with a game that has more than 7 million users who wrote their game in C++ and were able to port it to both Android and iOS without writing two different games. And really there are only two mobile platforms that users have to worry about, iOS and Android.
Internet based HTML5 has an intrinsic latency due to the connection with the server. Therefore the bottleneck for performance is not cpu but rather network latency., his makes much of the discussion concerning tailed suite moot, because the real issue is data delay and not code generation optimization.<p>Lastly performance comparisons between Java and javascript hint that portability of code is not the bottleneck: because Java is much faster than javascript while still being portable.
Also amusing, WebGL is provided as an example of why perf is good, but is it really part of HTML5? The assumption that it is appears to be another myth.<p><a href="http://www.w3.org/TR/html5/" rel="nofollow">http://www.w3.org/TR/html5/</a>
<a href="http://stackoverflow.com/questions/10185554/is-webgl-part-of-the-html5-specification" rel="nofollow">http://stackoverflow.com/questions/10185554/is-webgl-part-of...</a>
HTML5 means that some elite browser developers enjoy fun and performance native coding and they allow us to use only crappy HTML/CSS/JavaScript (altjs languages and Emscripten can't compensate, of course).
I suspect Mozilla guys regard themselves as privileged classes or something.<p>As a programmer, the freedom of programming languages and APIs is more important than Apple tax.<p>I sometimes imagine a catastrophic future. They say all programmers will write software only on the browsers. Then, all programmers will forget how to write C++, and no one will be able to maintain browsers eventually :p<p>IMO, the easiest way to prove HTML5 is a prison rather than open will be jailbreaking Firefox OS phones.
> HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology.<p>That's a false dichotomy all the way through. Why "web" apps have this advantage "by definition"? "Web" means network. Nothing more. That has nothing to do with its independence of environment. Actually, independence is also a false statement. Web apps are in fact very much dependant on the environment they run in - the browser. To the point that you can't do anything outside of what the browser allows you to. Then also this trait is not unique to HTML apps - Java and .NET are exactly the same, just an order of magnitude more powerful.
I love the "cost of porting to other platforms" argument. I'd like to replace it with the "cost of delivering mushy web applications to customers who expect more". That cost is infinite, and you'll never get it back.