(I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
Desktop applications with a Web Based UI I think is the way to go. I love Desktop applications, but being able to just open a browser and use an app from my phone or tablet, regardless of whether they're iOS or Android, or whatever is better than developing a full blown native application that doesn't work "everywhere". There's more applications like that, but I leave that fun to others.
I have worked with Internet services for many years. I think we have missed quite some opportunity to build great web app platform.
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap certs makes this argument null and void. Does anyone have any recommendations?
Also, I think it's been shown that the overhead of encryption isn't that expensive these days.
What's completely broken about it? If you use it the way it was intended to be used, as a cache for apps, then it works perfectly fine in my experience. It behaves like a native app that updates itself in the background (Chrome itself does this, for example). If you try to use it as a HTTP cache then yes, it's completely the wrong tool for the job and you're gonna have a bad time.
Comments
I love the idea that we can make web apps just as successful as native apps, but the reality seems to be the opposite.
Mobile web usage went from 20% to 14% according to flurry from 2013 to 2014.
That trend could be reversed with a new movement towards the web, but it seems like it would take quite a trend reversal.
We're stuck with apple- and google- based rent seeking platforms.
http://www.flurry.com/bid/109749/Apps-Solidify-Leadership-Si...
We need installable, offline web apps.
They are working on it, but it is late.
https://github.com/w3c/manifest
(I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
They exist with a different approach from what you're thinking:
CherryMusic - https://github.com/devsnd/cherrymusic SABnzbd - http://sabnzbd.org/
Desktop applications with a Web Based UI I think is the way to go. I love Desktop applications, but being able to just open a browser and use an app from my phone or tablet, regardless of whether they're iOS or Android, or whatever is better than developing a full blown native application that doesn't work "everywhere". There's more applications like that, but I leave that fun to others.
I have worked with Internet services for many years. I think we have missed quite some opportunity to build great web app platform.
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
Like these? https://developer.mozilla.org/en/Apps/Quickstart/Build/Intro...
AppCache sucks. It's completely broken.
At least we have the Service Workers spec[0] coming soon, though, which should solve the problem.
[0] https://github.com/slightlyoff/ServiceWorker/
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap certs makes this argument null and void. Does anyone have any recommendations?
Also, I think it's been shown that the overhead of encryption isn't that expensive these days.
The cheapest certs I've found are from https://www.gogetssl.com/domain-validation/comodo-positive-s... but the wildcards are still pretty expensive. I can't recommend them though as I haven't bought one yet.
You can get cheap wildcard SSL from here - http://bit.ly/cheap-wildcard-ssl-cert.
Heer you can find Comodo PositiveSSL Wildcard at $58.36/Year.
What's completely broken about it? If you use it the way it was intended to be used, as a cache for apps, then it works perfectly fine in my experience. It behaves like a native app that updates itself in the background (Chrome itself does this, for example). If you try to use it as a HTTP cache then yes, it's completely the wrong tool for the job and you're gonna have a bad time.