This isn't a new topic for this blog, but as a good buddy of mine asked me about this yesterday, and we ended up having a good conversation about it on IM, I thought it would be nice to write up what we discussed so I could share it with others. The conversation started with a simple question:
Are you a proponent of local and session storage for hybrid apps, since web sql is deprecated?
Let's begin by thinking about the kind of data you need to store in your application. (And I'm going to begin by considering all web apps, not just hybrid mobile apps.) In general, I break down storage into two types:
- The first type of data is what I call "known data sets". That is *not* a great term, but it basically means the data is consistent and doesn't expand infinitely. An example would be remembering the user's login name so that you can pre-fill the value the next time they login. Another example would be their preferences, things like what menu items should be shown and how they like to use the site. Another example would be a shopping cart. While this is - technically - dynamic - it is still a known quantity - an array of product items and quantities.
- The second type is what I call "unknown data sets", and again, this is a *really* bad term. This isn't random data you know nothing about of course, but rather data that can grow in a matter you can't really estimate. An example of this would be a To Do list. Another example would be a note system like Evernote. Another aspect of this data is that due to it's unknown size and content, typically search is a required feature to work with the data.
These are broad, fuzzy categories and obviously you can probably think of examples that would fit in either block, but this is the "mental map" I use to help me decide how I'm going to store data in a web application.
Within these two categories, I consider these technologies:
- "Known Data Sets": Cookies, WebStorage (covers both Local and Session storage)
- "Unknown Data Sets": WebSQL, IndexedDB, and for mobile only, the File system
So for the first group, I almost always prefer WebStorage to cookies. The API is a heck of a lot easier to use. Less people block it. (In fact, you can't block WebStorage. You can - of course - delete or modify the data by hand.) In general I'd only do maintenance work with cookies. I can't imagine every adding cookies to an existing site.
The second group is a bit trickier. WebSQL is deprecated. You aren't supposed to use it anymore. IndexedDB (IDB) is "proper" way to store deep, complex data and should always be used. Except... IDB can be difficult to use. I've heard the exact opposite too, but at least for me, coming from a background of building server-side apps with ColdFusion, SQL was pretty familiar to me. IDB is also incredibly bad on iOS. You can read my original article on (IndexedDB on iOS 8 - Broken Bad. Things are definitely improving in the most recent versions, but for a long time, WebSQL worked much better on mobile than IDB did.
So what would I choose?
On hybrid, I'd probably lean towards using SQLite. This is plugin-based so it is a known quantity and you don't have to worry (too much) about weirdness with the browser on the device and as I said - it may be more familiar and easier for folks than IDB.
On the desktop, I'd probably lean more towards IDB. Support is pretty solid and as long as you have good fallback, you're fine with older browsers.
Of course, an even easier solution would be to consider PouchDB, which abstracts away these details and picks the "best solution" for your current browser. I haven't used it a lot as the biggest feature of it is "sync", and generally I'm more concerned about just the local storage, but from everything I've seen it is a damn good solution and incredibly well supported.
Want to learn more? (Warning - advertisment!) You can purchase a 2+ hour video series on the topic I created for O'Reilly or purchase the book I wrote on the topic. (Or both. ;)
Archived Comments
“Things are definitely improving in the most recent versions…” should be “They rewrote the entire thing and fixed the bugs; it’s shipping in 2 months. ALL ABOARD THE HYPE TRAIN!” 😊
Heh - and the best thing about iOS is that like 99% of folks will have the new version within a week.
It took iOS 9 about 3 months to reach 80%: https://mixpanel.com/trends... (it’s now at 91%), which seems pretty good. So… early next year I expect a new wave of practical tutorials on IndexedDB from the relevant authors 😅.
Heh, to be fair, all the old tutorials should still be 100% valid.
As an aside, were you aware Google added a view of all your IDBs?
chrome://indexeddb-internals/
I meant to blog that before I left for vacation just to help spread the word.
True, but with posts that are 2+ years old, there’s always a risk that some parts are outdated. I recommend updating older posts, at least the most popular/relevant ones. The process could go like this:
1. Pick an older post for review
2. Update outdated information
3. Check if links/demos are still functional
4. Add new text if appropriate (e.g. updated advice, new developments)
5. Add “Updated on …” box at the top with a summary of changes
6. Share updated post on social media
Oh lord thats a lot of work. I've got 5.5k+ blog posts here and there's no way I can keep them all updated. ;) But you *are* right about posting some new content. Once 10 is final it would be a great time to remind folks about the feature, show an example, etc.
https://github.com/litehelp...
is the most suitable option for client side storage on both android and ios.
For my Ionic apps, i access my data through a service. Everything i store in localstorage, i mirror to SQLite (simple table with 2 fields, key, value). On App start i fill the localstorage w/ the data stored in SQLite. I did this because iOs tends to clear localstorage when the device storage gets low. It leaves SQLite untouched
Interesting... so you store it *twice* locally? I have to ask - why? I know LocalStorage is super easy, but SQLite isn't too difficult either. Why not just use it alone?
Because LocalStorage is synchronous. And I retro-fitted it into an app and this way i didn't need to change too much to code accessing and writing to the localstorage. I could just change localstorage.get/setItem to StorageService.get/setItem. In a new app I could do without LS
I know this topic is older but I would recommend localforage, its a shim but its very easy to use and worth trying out.. I personally use localforage for larger data-sets to prevent the localstorage 5 meg limit and load in the objects to memory on run, this way its very fast but persistant between restarts.
"Older"? I wrote it about 20 days ago. :)
https://developer.apple.com... says "Safari’s IndexedDB implementation now fully supports the recommended standard. You may now use the API to store structured data for web applications that work offline or that require large amounts of client-side data caching."
Yep. I haven't tested it yet, but it is good news.
If you implement an app for caching say, last 200 users' names & avatars URL by ID, would you go with localStorage or indexedDB? Assuming avatars (binary) is taken care of by Cache API?
I'd probably use IndexedDB. There are some really nice libraries for it now making it a lot easier to use.