I am in the process of implementing an "offline" option of a web application and am uncertain wether to proceed with the HTML Application Cache or the browser cache.
There are several aspects of the Appcache that make it attractive, name the ability to leverage the FALLBACK section to support the loading of a "minimal" version of the app if the client is disconnected.
My primary concern with the Application Cache is it's longevity and browser support. While I am willing to only support modern browsers, I fear the Application Cache may become phased out in future HTML specs. This fear is founded in this line of the current spec :
The following features are at risk and may be removed due to lack of implementation.
Application Cache
http://www.w3.org/TR/html5/
Any insight into this would be greatly appericiated.
Related
From MDN：
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Because it was replaced by Service Workers.
AppCache has a not so good API design and Service Worker can be used more flexible.
Is ServiceWorker intended to replace Appcache, or is the intention that the two will coexist? Phrased another way, is appcache about to become deprecated?
Blink's Service Worker team is keen on deprecating AppCache (We will follow our usual intent to deprecate process). We believe that Service Worker is a much better solution. Also, it should be pretty easy to offer a drop-in replacement for AppCache built on top of SW. We'll start by collecting usage metrics and do some outreach.
AppCache and Service Worker should coexist without any issue since offering offline support via AppCache for browsers that don't support Service Workers is a valid use case.
#flo850 If it's not working, please let us know by filing a bug.
I must say that Services Worker is not only the replacement for AppCache, but it’s far more capable. An AppCache can’t be partially updated, a byte-by-byte manifest comparison to trigger the update seems odd and there are several use cases leading to security and terrible usability problems.
Even Chrome and Firefox are planning to stop support for AppCache in the near future. Now that service workers are supported by Chrome, Opera, and Firefox.Also, The noises coming from Microsoft and Safari have been positive with respect to implementation and under consideration.
As a cache tool, it will coexist with appcache. Appcache works on virtually every browser.
But service workers are a solid foundation that will permit new usage like push (even when the browser is in the background) , geofencing or background synchronization.
Is HTML5 Application Cache different from browser cache?? If so, in what aspects, it is different and how this mechanism works?? And tell me how using AppCache we can improve browsing performance.. Also discuss about the pros and cons of HTML5 AppCache (its expiry and storage size limit etc.,)??
HTML5 Cache
HTML5 provides application cache, which means that a web application is cached, and accessible without an internet connection.
Application cache gives an application three advantages:
Offline browsing - users can use the application when they're offline
Speed - cached resources load faster Reduced server load - the
browser will only download updated/changed resources from the server
Browser cache
Internet browsers use caching to store HTML web pages by storing a copy of visited pages and then using that copy to render when you re-visit that page. If the date on the page is the same date as the previously stored copy, then the computer uses the one on your hard drive rather than re-downloading it from the internet.
References -
http://www.w3schools.com/html/html5_app_cache.asp
http://www.pctools.com/security-news/what-is-a-browser-cache/
The new HTML5 specification allows browsers to prefetch some or all of a website assets such as HTML files, images, CSS, JavaScript, and so on, while the client is connected. It is not necessary for the user to have accessed this content previously, for fetching this content. In other words, application cache can prefetch pages that have not been visited at all and are thereby unavailable in the regular browser cache. Prefetching files can speed up the site's performance, though you are of course using bandwidth to download those files initially.
AppCache has been deprecated.
See Google's note on it and Mozilla's. Google recommends using the service worker Cache API (which Mozilla classifies as an "experimental technology"). Note: compatibility with Safari is limited.
Difference
AppCache is specifically designed to allow web apps (and web sites) to be made available offline, though the same speed benefits which the normal browser cache provides, when the user is online, are also provided by AppCache.
The key difference with the Browser cache is that you can specify all the assets the browser should cache in a manifest file (conceivably your entire site) whereas the browser cache will only store the pages (and associated assets) you have actually visited.
What is new in HTML 5’s “offline web applications” feature which was not already available in all browsers?
Offline caching is the job of the browser — how did it become a job of HTML?
A web cache is a mechanism for the
temporary storage (caching) of web
documents, such as HTML pages and
images, to reduce bandwidth usage,
server load, and perceived lag. A web
cache stores copies of documents
passing through it; subsequent
requests may be satisfied from the
cache if certain conditions are met.
As written in Wikipedia’s article for Web cache.
And this is written for offline web cache in the W3C website:
In order to enable users to continue
interacting with Web applications and
documents even when their network
connection is unavailable — for
instance, because they are traveling
outside of their ISP's coverage area —
authors can provide a manifest which
lists the files that are needed for
the Web application to work offline
and which causes the user's browser to
keep a copy of the files for use
offline.
What is HTML 5 doing better and different in caching?
Is it similar to offline mode in Internet Explorer 5? And can we cache the data beyond the limit of amount of space set in browser?
Please give me an example so that I can understand the difference of HTML 5 offline cache, and browser caches.
Web browser caching is when browsers decide to store files locally to improve performance. HTTP allows web servers to suggest browsers how long to store the files for, and allows browsers to ask the server whether a file has changed (so that they can avoid re-downloading it).
However, it’s not designed to reliably store assets required by an offline application. It’s ultimately up to the browser whether, and for how long, it caches the files. And browsers will often stop using their cached version if they can’t contact the server to check that it’s up-to-date.
The HTML5 offline web applications spec provides web authors with the ability to tell browsers what to store for offline access, and requires browsers to keep those files up-to-date when it is online. It also provides a DOM property that tells the developer whether the browser is online or offline, and events that fire when the online status changes.
As Peeter describes in his answer, this allows web app developers to store user-inputted data whilst the user is offline, then sync it with the server when they’re online again. The developer has to do this storage and syncing manually, as the browser only provides the events indicating online status, but if the browser also supports localStorage, the developer can store the data there.
I can do no better than point you to the relevant chapter of Dive into HTML5: http://diveintohtml5.ep.io/offline.html
You can now cache dynamic data, instead of just js/css/html files / images.
Lets say you've got a todo list application open in your browser. You're connected to the internet and you're adding a bunch of stuff you have to do.
Boom, you're on an airplane without a connection. You've got 6 hours of time to kill so you decide to get some work done. You finish all of the things on your todo list (the list was still open in your browser). You select all of the items and change their state to "finished".
Your plane lands, you open up your laptop and refresh the page. All the changes you did without a connection are now synced to the server as you have a internet connection now.
With many browsers adding proper local storage support (and with this whole HTML5 buzz), there is a lot of talk about offline web apps competing with desktop software. But, as a matter of fact - one quick "clear private data" on your browser (which a lot of people do) - clears all the local storage data.
I'm now thinking that local storage in browsers can at best be used to cache data temporarily before being sync-ed with the web server, but truly offline web applications can't rely on HTML5's local storage permanently due to the problem I outlined above.
Is there a scope for offline web applications that actually depend on data extensively?
My take on this is that the offline capability of online web apps can compete with desktop software, but not pure offline web-apps.
Why? Well, the major drawback of online web apps was what happens when you lose your network connection when doing any work. Seeing as this can be resolved now, the competition is truly on. Imagine editing a document online, then move around without internet, come back online and then sync the changes and continue to work as if nothing happened. That is truly awesome.
For this to work, the browser should allow to store data in a location that you can pick which would mean access to OS layer, which will probably not happen anytime soon...