Basket.js.next and Service Worker

[addyosmani]

@wibblymat is currently working on a new caching library called Shed that builds on top of Service Worker's Cache API.

In the past, we've discussed how we think the Cache API might be a more suitable destination for cached scripts and stylesheets than localStorage and with Chrome now supporting it natively, it's worth us discussing whether basket should evolve, or stay the same.

I see there being two paths here:

1. basket.js stays as is, a focused POC library for script/asset caching that just uses localStorage. We maintain updates to it to keep it working but otherwise don't plan to evolve it further.

2. basket.js is refactored to support SW caching. We either consume Shed or implement a lightweight layer that uses the Cache API polyfill to support other browsers but ultimately switch from localStorage to the newer API for where assets get cached.

I'm interested in thoughts on whether this makes sense at all and what folks think :) cc @passy @sindresorhus . Ideally, would love to avoid duplication of efforts.

[sindresorhus]

The future is definitely with the SW Cache API and not localStorage.

We either consume Shed

If so, what would it add it add upon Shed?

implement a lightweight layer that uses the Cache API polyfill to support other browsers

Isn't that what Shed is attempting to do?

[wibblymat]

@sindresorhus Shed is intended to be a general set of tools for SW
developers, while Basket has a specific use-case. Basket should be
something you just include in your page and it just works, Shed will need
plumbing in.

On Mon, 29 Dec 2014 10:33 Sindre Sorhus [email protected] wrote:

The future is with the SW Cache API and not localStorage.

We either consume Shed

If so, what would it add it add upon Shed?

implement a lightweight layer that uses the Cache API polyfill to support
other browsers

Isn't that what Shed is attempting to do?

—
Reply to this email directly or view it on GitHub
#131 (comment)
.

[sindresorhus]

Then yes. I think Basket.js should be rewritten to depend on Shed.

[addyosmani]

Let's coordinate with Mat when Shed is ready for broader use then :)

[addyosmani]

Update: We're planning on exposing the Cache API as a global (probably in Chrome 43) per https://chromium.googlesource.com/chromium/blink/+/53d80dc622ba866d563d4934c98777a42d4c3e96. This would open up the door to basket switching over to using that API.

We have some choices there. Do we become a tiered solution? i.e if Cache API is present, use that, otherwise use localStorage - or - do we attempt to switch to a Cache API polyfill (which would mean relying on IndexedDB)

[sindresorhus]

IndexDB doesn't have perfect browser support: http://caniuse.com/#search=IndexedDB So not sure. Depends on what browsers we want to target.

[puzrin]

While IdexedDB support level is acceptable, it's init is not free. A week ago we had to investigate why JS starts with noticeable delay at our site (we used bag.js with indexeddb prefered storage). Result is:

• IndexedDB init (~ first access) takes about 200ms.
• Script insert into page takes about 500ms (~150К gzipped/minified).

No ideas now to reduce this :(