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.
There are "uncomfortable realities" associated with native development as well, such as the cost of porting to other platforms, forcing users to upgrade their hardware to stay current, app discoverability issues, etc.
On the other hand, while it is rapidly getting better, the tooling for HTML5 apps are still generally the wild west. You can hack together an HTML5 app in no time, but unless you are doing something that is completely bog standard, by the time you properly engineer your HTML5 app, you probably could have delivered on two or three native platforms.
- forcing users to upgrade their hardware to stay current
If your app needs something from newer hardware to function properly (more processing power, new I/O devices, etc.), how does HTML5 alleviate that problem? If you mean forcing users to upgrade their operating systems (which is sometimes dictated by the hardware) for new features, I'll note that the browsers/HTML5 rendering systems are generally part of that upgrade, still requiring said upgrade to use those features in HTML5.
- app discoverability issues
Given that a native mobile app can use all of the same marketing tools a web app has, plus the vendor's app marketplace, couldn't it be said that native apps have better discoverability?
Where in mobile can you live-debug an application both visually and functionally like you can with Web Inspector? I mean literally you are coding and debugging your app at the same time. And with LiveReload you don't even leave your editor to see your code changes instantly.
Not to mention you are coding in JavaScript and CSS so the time it takes to iterate between various solutions is a fraction of the time of Objective C or Java. I think you have your first point backwards. There may not be an equivalent IDE, but we have a runtime inspector/editor baked into our runtime platform. You can't beat that.
- forcing users to upgrade their hardware to stay current
On Android you can update your default browser through the app store.
- app discoverability issues
Perhaps, but then again your app could just be rejected/removed at any time. Plus the whole 30% cut, time to release, limited sales options, etc. You're not in control of your app.
> Where in mobile can you live-debug an application both
> visually and functionally like you can with Web
> Inspector?
Visually? Interface builder in Xcode. Functionally? Instrumenta, lldb.
> coding in JavaScript and CSS so the time it takes to
> iterate between various solutions is a fraction of the
> time of Objective C or Java.
You are vastly underestimating the capabilities of Cocoa Touch and UIKit. And tell me, how many iterations will it take to reimplement something like reusable cells in UITableView with comparable efficiency in CSS and JS.
> Plus the whole 30% cut
You get a lot for that: including hosting, payment processing, automatic notification about upgrades and access to millions people with credit cards a click away from your app.
No matter, saying HTML5 tools are the "wild-west" was "wildly" inaccurate.
On the UITable thing... the efficiency is the whole point of this article. Does you UITableView code compile directly to any other platform?
As for implementing, from a quick google search it looks like it would be trivial. A one day project, if less. How long would it take you to RE-code it in cocoa from scratch without going off the original code? Also, see Enyo if you want an easily re-usable kit like that[1]. Not to mention tons of other ones. If anything that example works in favor of HTML being easy and open.
I feel you may have completely missed my point about it being the wild west. Android, iOS, and many other mobile platforms provide a rich set of frameworks that solve much of the hard engineering challenges for you.
HTML5 gives you a programming language or two and some rough system interfaces. By the time you are done your HTML5 app, it should be almost indistinguishable from a native app in terms of code, but you will have had to build many of those frameworks yourself; or, at best, extend one hundreds of competing frameworks that get you half way there but never all the way (again, unless you are doing something really simple).
As mentioned, I do agree that this area does improve each day, and the time may come where it does meet, or even exceed, what the native platforms offer. In the meantime, however, you are going to be spending a portion of your development efforts being part of that improvement cycle instead of moving on to the next native platform. Six of one, half dozen of the other.
Additionally, the reason I called it the wild west was in reference to the many HTML5 developers who choose to forego best practices altogether and program their app close to the "bare metal", doing only the bare minimum to get their app running. This provides a much shorter learning curve and quicker time to first product, which many non-native developers even consider a strong selling point of HTML5, but it sacrifices all of the lessons developers have learned over the past 30 years or so. Once upon a time, we used to program native applications that way too. Why sould we consider it a good idea now when it wasn't deemed a good idea back then?
forcing users to upgrade their hardware to stay current
I don't buy this argument. On my iPhone, the native apps perform great. It's the webpages I visit that sometimes cause slowdown. Yes, version of natives apps can come out that require an upgrade. But if an HTML5 application does not run well on current hardware, then a hardware update would be at least desired.
In other words, I think it's an issue for both native and HTML5, which means it can't be used to distinguish the two.
Fact: In fact, B is true, and even though A is true too, it is because C, D, and E, and in case where conditions X, Y and Z are imposed, the effect of A being true can be reduced significantly. Also, it is unfair to say that A is true because A was also true many times before and M is also true sometimes which is better than A not being true.
How it is "busting" any "myths" is a mystery to me, but journalists seem to love this pattern. Most use it gets in politics, especially near the elections, but popular journals on any topic love it too. Now Mozilla joins this venerable tradition.
