HTML and CSS Reference
In-Depth Information
Managing Client-side Data
Although we have aspects of a working web application, clearly there is a major flaw in the
current implementation: every time the user refreshes the tasks.html page all the tasks are
lost.
In this section we are going to examine ways in which we can maintain the state of the ap-
plication (the tasks) between page refreshes without utilizing server side storage.
Traditionally the only mechanism for storing data on the client in a way that survives page
refreshes was cookies. A cookie is a simple text based name/value pair that is stored on the
client. The server can set a cookie on the client by including it in an HTTP response.
Every-time the browser sends an HTTP request to a page on the domain from this point for-
ward, the cookie (both its name and value) will be included in the request.
Cookies can also be created and interacted with (with some restrictions) using JavaScript.
Cookies are great for managing some data. For instance, it is common for web sites to store
a session ID in a cookie to represent each user's individual session. This allows the server to
differentiate each unique session, and keep them separate. This is essential, since HTTP is
a stateless protocol, and there is no other inherent way to know that two HTTP requests are
actually from the same browser session.
While cookies are great for storing simple data on the client, they are not great for storing
large amounts of data such as our task list. Cookies have significant limitations that make
them inappropriate for storing large amounts of data:
1. They are included on each request to the server, so unless you want the entire task list to
be included on each request, cookies are not a good solution.
2. The maximum size of each cookie is approximately 5 kilobytes.
3. The maximum number of cookies that a single domain can store is 20 (this can be browser
dependent). This means that the total amount of cookie storage available to a domain is less
than 100 kilobytes.
It has therefore been evident for some time that HTML needs some form of offline data stor-
age if it is to allow for rich and dynamic web applications that can exist independent of a
web server. Even applications that are continually connected to a web server can signific-
antly improve user experiences if they could cache larger quantities of data on the browser.
There are now three distinct APIs for storing data on the client, all of which fall within the
umbrella of HTML5.
