Am I the only one getting fed up with these stupid "religious" wars in much of the IT world?
There are many valid cases where native is the better approach and others where web-app is best ! Any decent developer will do their homework and select appropriately.
BTW - many of the 'problems' high-lighted on the graph apply to both Native and Web-apps and there are some additional ones with Web-apps but I can't be bothered to spell them out. Bah !!
Even this highly simplified view changes once you have the app installed. With a native app, you have an icon right there on the user's home screen. The web app would require more typing and clicking.
This is true in Chrome, Windows and ChromeOS as well. Android probably does too, although I don't know for a fact. The notion that a web app is "just a web page" is really starting to fade away.
A lie by omission. They forgot to warn (following their warnings upside down):
1. Website can be malicious, too. Phishing, clickjacking, XSRFs, browser exploits - there's a lot of nonpleasant stuff on the web.
2. Websites can't manage memory and other resources at all. Sure, you, for example, can try to measure performance and disable UI effects, but that's another story.
3. In a same way, users must have enough of free space where browser's application cache is kept, too. Or you'll strain network re-downloading same data over and over again. This is especially annoying for roaming and other areas with high $/MiB cost or countryside with slow GPRS connectivity.
4. Website can fail, too. And if this is not some user-local network problems, this is more disasterous than a crash of a single copy of app on someone's device - your "webapp" works for noone at that time.
5. And, obviously, in a same way as removing the app, users could delete the bookmark for your service.
Should add a few, too, like "hope wireless connection works well or that developer properly prepared manifest," or "hope the developer didn't just assume 'web app' meant 'test in Safari Mobile only,'" etc.
And of course, this whole thing ignores an entirely different entry point "Discover new app". It assumes you are specifically searching for the app in question. What the app store and it's ilk offer is exposure. Angry Birds has been near the top of the top 25 on the app store since launch, and that alone drives continuous sales.
If you're an incredibly well-selling web app, you STILL have to market and spend and shout to get yourself known. No matter how well you're doing, your word of mouth still probably doesn't beat Apple's Top 25 board.
The App Store offers exposure to a few hundred applications that are at the top of their category due to intentionally difficult to predict algorithms; relying on this mechanism for users discovering your app is asking for failure and makes about as much sense as making a web page and hoping that it appears on the front page of a website catalog/portal like Yahoo for the lifetime of the product. For 99.99% of the applications in the store, people are going to be finding out about it from online reviews, word of mouth, and search engines.
HTML5 support for things like geolocation / camera usage is inconsistent across models and generally brittle. The upside is that mobile web is really low friction and allows for instant deployment, but there's functionality and no good management system like the home screen.
I've used the Quora web app occasionally. But if I had actually had a Quora app on my home screen, I'd use it far more frequently.
Web applications can be icons on your home screen (at least on the iPhone): just click (+) and "add to home screen". If the application is setup correctly, when spawned in this manner it will also appear without any browser chrome, allowing it to be a truly full screen application.
Oh man, they should really tell Instagram / Angry Birds that their software will work as a webpage and that the user experience on a mobile browser will be that much better.
Uh, Angry Birds quite obviously works as a web page (http://chrome.angrybirds.com/?version=hd), haven't tried it on either mobile or computer browsers though. Just wanted to point out that even high-profile games such as that are indeed becoming available as web pages.
On laptops and desktops, sure, where there's enough of a computational surplus that the overhead isn't that big a deal. I'm not aware of a web-delivered version of Angry Birds that can work well on phones, though.
Angry birds in the browser is 100x worse than on the iPad. It feels like a totally different game. For a game like that, web apps can't really compete with native apps right now.
the distinction should be made of mobile web apps vs web apps.. cause there are tons of flash games that outshine Angry Birds in many ways. Just pointing out for clarification.
The question isn't "can it be done", but "can it be done well". Windows Mobile 5.0 could do 95% of what the iPhone could do (and a fair bit more). The iPhone did almost all of that 95% overlap better. Better can be the difference between a niche product and a product that changes an industry.
I don't think anyone will argue with you that the touch interface that the iphone came out with was revolutionary. the better comparison is Android vs iPhone. While you say this, the regular phone is still more abundant than the smart phone.
The only valid negative point I see here is "update app", which is really the web-as-deployment-platform's killer feature from a user's perspective. I do hate having to update 20+ apps on a regular basis, it should just be on-demand.
The problem with invisible updates is sometimes you don't want to get the update at all. This is especially true if you work in a corporate environment and you need to re-certify each version of the app for use on your work-provided devices.
HTML5's Application Cache can solve that to some extent. I believe you can prompt to user to ask if they want to update (though once it's updated there's no going back, or installing previous version initially, unless the site provides mirrors of old version)
This question is only going to be relevant if the application is already open: if you close your browser windows and then re-open the application it will use the latest cache and evict the older ones. In essence, this mechanism is designed to allow an application to operate with an atomic version of the resources it requires for operation, and is not designed to allow the user to manage old versions.
There are many valid cases where native is the better approach and others where web-app is best ! Any decent developer will do their homework and select appropriately.
BTW - many of the 'problems' high-lighted on the graph apply to both Native and Web-apps and there are some additional ones with Web-apps but I can't be bothered to spell them out. Bah !!