I had a doubt regarding HTML5 storage technologies like WebSQL, WebStorage/LocalStorage, and indexedDB and to a lesser extent appCache.
Considering the case of chrome (my default browser), these stores are maintained in chrome browser's own directory. Do they impact the starting-up time of the browser?
A colleague has said to experience browser slowing down or behaving in sluggish manner when a larger amount of data is stored.
Couldn't find references to how these technologies impact the browser working, so would love if any fellow-stacker could guide me.
Be careful : the WebSQL API is dead (it was based on sqlite instead of a generic API and so was judged not desirable by the Mozilla team, the Indexed Database API will be used instead but you should probably wait for it to be more supported).
LocalStorage is fine, I use it in all my web applications without problems nor measurable boot time. But keep it for parameters, preferences, and so on, as the only reliable storage is always server side. The local storage can be removed, lost, modified, not readable for many reasons (user uses another browser or computer for example). And it seems to me that a big local storage is a burden to the user and thus not very correct (which is probably the reason why this size is limited).
BTW, there is no reason a reasonnable local storage could slow in a measurable manner the launching of a browser.
I agree with dystroy; Normally the local storing is harmless if done the right way. Storing MASSIVE amounts of data in the browser on the other hand is quite discouraged. It won't slow down the browser performance overall but will slow down the web app using it (as far as I know, Chrome fetches the local storage values dynamically when the 'owner app' is called).
Related
I have a web application that uses a lot of offline storage. It was running good until the data increased and reached around 8MB. Whenever storing that much data to the WebSQL, I received error stating "The inspeted target has crashed." I assume that it has to do with the storage capacity, although I am not sure. Since everything was working fine until the data increased, I would like to check after increasing the WebSQL capacity. There is a post I read that talk about creating a manifest.json file. My question is
Does this work for web applications?
Where is this file placed?
What are the furhter steps to take after creating this file?
What about other browsers? Does this solve problem for only Chrome?
I think this has something to do with the implementation of your WebSQL. I have offline databases in WebSQL that are well over 100MB and load in Chrome without a hitch.
I have a 6MB binary file in my AppEngine backed app. I need to get this file to my GWT client to do many computations. I'm trying to avoid doing the computations on the server to save my instance hours quota. But this means I have to get the file to my client somehow.
I also don't want to download it to the app each time the app is opened, that would hurt my appengine outgoing bandwidth quota.
It would be nice to download it once, then have the client somehow store it for use the next time the app is opened.
How to best do this?
A ClientBundle? Use HTML5 Storage? Is this sort of thing just not done, and should I just do the computations on the server and send the result to the client?
The most easiest way to permanently cache the file is using application cache.
Another ways is HTML5 Storage (localStorage), but there is 2.5 MB limit. To use more than that amount, you have use IndexedDB (Chrome, Firefox, IE10) and WebSQL (Safari, Opera). A wrapper library like YDN-DB help in this case.
You can use DataResource:
https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#DataResource
The only problem you face is the file size. Different browsers have different limits - I've seen 5MB and 8MB numbers. If you can compress your file to be under 5MB, you should be fine with most browsers. (By the way, it's an enormous amount of data if it can't be compressed any further.)
Also, you can detect a mobile browser (or offer a different URL for mobile version), and do computations on the server for mobile users.
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...
While there are a lot of good stuff about html5, one thing I don't get is the redondant storage mechanism, first there is localstorage and sessionstorage, which are key value stores, one is for one instance of the app ("one tab"), and the other works for all the instances of that application so they can share data. Both are saved when you close your browser and have a limited size (usually 5MB), that's great and everything would be nice if we stopped there.
But then there is the "Web SQL Database", which has the same security system as the localstorage, the same size limit, the same everything except it works like/is sqlite, with tables and sql syntax and all of that.
And the bummer is, they don't work on the same data at all ! This is not two way to access your data, this is really two storage for every html 5 app out there (not created by default yes, but still you see my point).
What I would like to know is, is there a reason for both of this mechanisms to exist at the same time ? Or did they just look at sql and nosql movement to pick the best then went "screw it let's add both !" ? Why not implement local/session storage as a table inside web sql db ?
My take is that localstorage is a proper rewrite of the way cookies should have been done in the first place. It has a very simple api and low barrier to adoption.
Web SQL is pretty heavy duty and would be a serious pain for saving just a simple value so they have very different use cases. localstorage is actually implemented in WebKit using SQLite but just not exposed via WebSQL.
Session storage cannot be implemented easily inside the database as it is effectively in global scope and you don't want the data visible to other tabs. Because it is transient data you wouldn't typically want to store lots anyway so wouldn't need transaction and querying.
See also:
http://www.pubbs.net/200904/webkit/28373-webkit-dev-need-help-making-windowlocalstorage-span-processes.html
I asked myself the same question, and here is the answer, quoted from the Chromium wiki :
Q: Why this over LocalStorage?
A: LocalStorage is inherently racy or a
parallelism disaster, depending on
whether or not you're willing to
implement the "storage mutex"
described in the spec. Chromium has
decided not to implement it. WebKit
itself is single thread/process (i.e.
no parallelism period)
Source :
http://www.chromium.org/developers/design-documents/indexeddb
Web SQL can be useful if you want to copy the structure of your database locally for offline use.
But Web SQL will not be implemented in firefox :
http://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards
Mozilla, Microsoft and Oracle are working on the "IndexedDB" alternative : http://www.w3.org/TR/IndexedDB/
Work in progress in firefox : https://wiki.mozilla.org/Firefox/Projects/IndexedDB
Storage demos :
A good article from PPK about html5 storage : http://www.quirksmode.org/blog/archives/2009/06/html5_storage_t.html
Ian Hickson early 2008 session storage
demo :
http://www.whatwg.org/demos/2008-sept/wizard/step1.html