Tuesday, February 6th, 2007
Boost Ajax performance using local storage
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.
Conclusion
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:
- New Dojo Offline Release: Offline Files + Automatic Network Status
- Moxie demo application
- Latest Status report
It is cute that the namespace has “.dot.” in it :)
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.
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 ?
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.
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?
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.
@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.
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
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.
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…
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.
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.
Best,
Brad
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.
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.
http://www.patentmonkey.com/PM/patentid/7188305.aspx