Just a quick question about saving an apps state using local storage. I'm about to start work on an iOS web app and I'm wondering if there may be any advantages or disadvantage to either of these models. Also, is there any major performance hit to saving every tiny change of the app state into local storage?

Number 1

Save the entire app state object as an JSON string to a single local storage key value pair.

var appstate = {
    string: 'string of text',
    somebool: true,
    someint: 16
}
localStorage.setItem('appState', JSON.stringify(appstate));

Number 2

Save each variable of the app state to it's own key value pair in local storage.

var appstate = {
    string: 'string of text',
    somebool: true,
    someint: 16
}
localStorage.setItem('string', appstate.string);
localStorage.setItem('bool', appstate.somebool);
localStorage.setItem('int', appstate.someint);

Just a quick question about saving an apps state using local storage. I'm about to start work on an iOS web app and I'm wondering if there may be any advantages or disadvantage to either of these models. Also, is there any major performance hit to saving every tiny change of the app state into local storage?

Number 1

Save the entire app state object as an JSON string to a single local storage key value pair.

var appstate = {
    string: 'string of text',
    somebool: true,
    someint: 16
}
localStorage.setItem('appState', JSON.stringify(appstate));

Number 2

Save each variable of the app state to it's own key value pair in local storage.

var appstate = {
    string: 'string of text',
    somebool: true,
    someint: 16
}
localStorage.setItem('string', appstate.string);
localStorage.setItem('bool', appstate.somebool);
localStorage.setItem('int', appstate.someint);

• javascript
• performance

• 4 Why would you save all the small bits and pieces separately? What happens when you add another property foo? The Number 1 is much cleaner because you have to save/load only 1 item. I'm pretty sure that in terms of performances the sum all of parts is slower that the single item. – Toni Toni Chopper Commented Apr 23, 2013 at 15:42
• 1 @ToniToniChopper That makes sense. It's going to be a fairly simple app either way. Is there a performance issue with JSON.stringify() and JSON.parse()? – Phil Commented Apr 23, 2013 at 15:48
• No, don't worry about that especially if it is a simple app. – Toni Toni Chopper Commented Apr 23, 2013 at 15:51

2 Answers 2

The only reason I would think it could be more efficient to store values separately would be if you anticipate values changing independently of each other. If they are stored separately you could refresh one set of values without touching another, and therefore have better handling of value expiration. If, for example, somebool changes frequently but the rest does not, it might be better to store it separately. Group together data with similar expiration and volatility.

Otherwise, if you just want to save the entire application state, I would think that a single string would be fine.

Consider reads vs. writes (changes). For frequent reads, it doesn't really matter because JavaScript objects are hashes with constant (O(1)) response time (see Javascript big-O property access performance). For writes, as nullability says, there is a difference. For the single-object design, frequent writes could get slower if you end up with a large number of (or large-sized) properties in the object.