Tuesday, February 6th, 2007

Boost Ajax performance using local storage

Category: Dojo, Offline

Niall Kennedy has taken a look at the various local storage options from various browsers, and cross-browser in Boost Ajax performance using local storage.

His article touches on the good ole cookie, Flash local Shared Object, Internet Explorer userData, and Firefox DOM Storage.

He talks about pros and cons, and efforts such as dojo.storage.


Client-side storage addressable from any web page has the potential to change the way we build web pages and the division of labor between client and server. Just as CSS and JavaScript created new ways to style and interact with a page, the client-side storage capabilities of modern browsers will create a new concept of a web application runtime. It’s yet another step in the progression of web applications trying to create the best possible experience using the latest widely deployed web browsers and browser plugins.

Web applications using these latest technologies can deploy an upgrade on-the-fly, initializing a new set of libraries and web page templates after examining a user’s browser and bandwidth for compatibility. Web applications such as Google Calendar might store your appointments locally, exposing this data to Google Maps or other mapping applications to plan the route to your next appointment without submitting a new server requests for the same data. Your webmail will be downloaded locally, quickly loaded even if you are on a plane.

Speaking of dojo.storage, there is another update:

It is cute that the namespace has “.dot.” in it :)

Posted by Dion Almaer at 8:13 am

3.1 rating from 33 votes


Comments feed TrackBack URI

Yeah that’s great, store my appointments on my browser so when I get home I can… no wait… it will be stored in my browser at work, darnit.

Comment by Mark — February 6, 2007

Local storage is USELESS for web application, if you want local storage then use a local application. What is the point of using internet solutions to reproduce local applications ?

Comment by noname — February 6, 2007

Mark, you’re missing the point. The idea is not to just store your appointments on your machine at work, it’s to enable you to work offline so that if you don’t have an internet connection the functionality of your web app can degrade gracefully, still allowing you to do some work. When you go back online, this information can be synchronised back to the web.

This is a very common workflow pattern used in applications like Outlook, Lotus Notes etc, only adapted so that with a little work, web applications can offer the same facility, reusing the same UI and the majority of the code, without telling people they have to download a completely separate desktop application which may or may not even work on their system.

Comment by Shane — February 6, 2007

Shane, isn’t it all moot though? What I mean is when I try and use the web browser without an internet connection I usually get the browser providers “You are not connected” page. So unless I’m running the app on my loopback addy (which most users probably won’t), how would a browser-based web app ever degrade gracefully?

Comment by Mark B — February 6, 2007

That is a good point, Mark. I would personally like to see a video demonstration of how this might function. If it could work like Shane is suggesting, I could absolutely see the benefits in this. In fact, this might be the missing link to allow web applications to be taken more seriously by big businesses.

Comment by Brian — February 6, 2007

@Shane, @Mark:

I ran into the need for local storage recently with an app. The server-side system does not have a reliable/usable session management implementation but I needed to have the application “remember” the status of some javascript-rendered changes on the page. If the user clicked away from the page then hit the ‘back’ button, all changes would be lost and they’d have to start over. (It’s a system were 1,000s of records can be retrieved from a database with very specific criteria – could take the user a long time to compile the list)

This wasn’t acceptable “back button” behavior; local storage would have been a perfect way to remember the page state without being inhibited by the 4KB cookie limit. We ended up implementing a server-side storage mechanism combined with Ajax – but local storage would have saved some additional round trips.

Comment by Jon — February 6, 2007

TIBCO GI customers have thought of local storage for applications such as field inspections, repairs, or sales data entry capture. Consider the impact of insurance forms and the like being filled out in the browser without a connection to the network available. Then when retuning to the office, connecting and uploading that data. When you have 10,000 field agents on the move, it’s a compelling, simple case, where offline data for mobile business users makes sense.

Here’s a video tutorial from Ajax World 2006 that shows TIBCO GI’s Luke Birdeau incorporating dojo.storage into a Ajax RIA built with GI. … http://www2.sys-con.com/webinararchive.cfm?pid=wc_aw6_d1_s12_t1_birdeau

Comment by Kevin Hakman — February 6, 2007

I see a lot of use for local storage as a local cache of data (unlike the browser cache with can cache js/css/rendered html). In the email example, you could send the user all the message ids for that view and have the client ask for the full messages on a second request, but only for the message ids that are new. Those get added to the cache. If no new email, then the request/response is very small and fast.

Comment by Steven Roussey — February 6, 2007

I understand were Niall is coming from, but why not use the browser cache to do caching instead of local storage? The application can certainly use local storage for that purpose, but then it needs to implement expiration and refresh policies…

Comment by Julien Couvreur — February 6, 2007

I agree about how much of this is completely moot– watching the Adobe apollo demo, while there are lots of merits in that platform, working in a disconnected state for a browser-based application just seems like a lot of development work in maintaining multiple states for everything. I’ve done handheld development with ‘offline’ storage, but that was a specific requirement for a standalone application– not a browser-based application.

Comment by Jacob — February 6, 2007

Julien, I’ve investigated using the local browser cache for storage. There are two problems. The first is the cache pinning problem, which Firefox 3 is going to try to tackle. But the biggest issue is application-created information; how do I ‘POST’ some bit of new information into the cache? Browsers don’t currently allow a web-page to ‘save’ something into the browser cache.


Comment by Brad Neuberg — February 6, 2007

Web applications using these latest technologies can deploy an upgrade on-the-fly …

Web applications 15 years ago could also web upgraded on-the-fly, by changing the web code. What a technological breakthrough! Client-side storage is minimally useful, at best. Use the web for its strengths, use a desktop for its strengths. With the amount of people always connected to the internet, if you need off-line applications make them native applications.

Comment by Dan — February 7, 2007

The first two comments on this article demonstrate the shortsightedness of most web developers. Which is nice because it let’s those who actually understand the importance of this, build better web applications. If you can’t think of why off line storage is important to web apps then you’re obviously in the wrong field.

Comment by Jim Plush — February 12, 2007


Comment by jimmy — July 20, 2007

Leave a comment

You must be logged in to post a comment.