Certainly the concepts have been covered repeatedly in countless articles, books or papers you can imagine, digging into the territory of Web development: server-side and client-side programming. While nowadays these areas are clearly differentiated and stand on their own in distinct scenarios, the requirements of modern websites demand heavy interaction between them. From database-generated navigational menus, to server-based CSS style manipulation, examples of server-client programming interaction are truly vast and numerous.
Of course, here we're discarding any other well-known client-side storage process, such as cookies, image-based data tracking, data coming in from local cached files or even from XML files. This issue immediately brings to mind a question that has caused several heated discussions: is it good to store data in the client this way? The range of opinions varies widely from a rough complaint to a resounding yes. The truth is that the answer is hard to give, since it relies strongly on several factors, such as amount of data, type, user hardware (remember we're using client system resources) and particularly data relevance.
Definitely, we'll agree that no critical data will be stored in the client, even if this sounds like common sense stuff. If you ever thought that critical information should be stored in the user's environment, please change your mind right now! However, regarding my personal experience, when building applications that heavily eat up a client's computer resources, difficulties can easily appear, causing browser crashes or complete system hangs.
But, all is not lost. As hardware rapidly evolves, and it's widely available to average users, there are certain cases where it is possible and even desirable to have a small application directly using the client's memory to store temporary data.