Comment by jaredsohn | Hacker News Reader

Comment by jaredsohn | Hacker News Reader

Instead of caching the model in LocalStorage, couldn't you also just store it in the extension's background page? You would simply store the data that you would otherwise put in LocalStorage within a variable on the background page. From the popup, you can access background page variables as members of the object returned by calling chrome.extension.getBackgroundPage().

The extension would still need to recompute it once every time it is starts up, but since it is computable I don't think it belongs in LocalStorage. (You wouldn't store something like this in the registry if you were writing a Windows program; you'd just keep it in memory.)

Also, the article could use a bit of improvement in terminology. When it talks about 'loading the extension', it really means displaying the popup. I think of loading the extension as in starting up the background page via the extensions window.

Good point I'll see if I can clear up that terminology in the post.

You are also correct that you could use the background page as an alternative persistance layer instead of LocalStorage. LocalStorage is obviously more applicable in non-extension environments. Is there a big benefit to using background pages in a Chrome Extension over LocalStorage simply for storage?

One thought for future work: load the Backbone app into the background page when the browser starts. Whenever the popup loads, simply update the Viewport view's element with Viewport.setElement() to be the root popup body element. This might allow persistance between popup loads.

The benefit isn't that big.

From the standpoint of writing quality code, I think it is better to use the background page instead of LocalStorage in that it lets you avoid writing to disk (which requires space and has worse performance than using memory, although at this scale the difference is trivial) and doesn't pollute your LocalStorage namespace as much.

An advantage of the LocalStorage approach is your readers can write code in a way similar to how they would if you were not writing an extension and it makes the material more accessible in that it requires less understanding of how Chrome extensions work.

two points

-localStorage works on the background.html page

-when content scripts access localStorage, they do so at the domain level of the url

I don't understand the purpose of your points here.

* localStorage also works from the popup (using the same storage as the background; that's how the tutorial was able to work).

* We're trying to get data working in the popup here, so how localStorage works in the contentscripts is irrelevant for solving this problem.

Reply on news.ycombinator.com