Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

better than appcache? #71

Closed
davidmarkclements opened this Issue Jan 19, 2013 · 18 comments

Comments

Projects
None yet
6 participants

Hey guys just a quick (burning) question - whats the percieved or intended benefits to using this over appcache?

Best,
Dave

jkroso commented Jan 22, 2013

you can fork it!

Contributor

sindresorhus commented Jan 22, 2013

Because AppCache is a douchebag

basket.js gives you more control, but is only for JS. Research both and pick your poison.

We're going to write a better comparison of the alternatives in the future.

hey sindresorhus, yeah I read the alistapart article some time ago, however once you know the gotchas, for simple usage (eg equivalent to basket.js capabilities) appcache seems to be fine - plus theres no need to load a library up front, and no delay for initial execution time.

is it a case of trading off performance with simplicty that basket.js provides? If thats the case then a tool that automatically generates and manages a manifest file for you can do the same without the performance hit..

or is localstorage actually faster than appcache, thus compensating for additional load/parse/execution overhead?

also, images/css - basket js could do these too? Unless theres limitations on the localstorage (eg where a lot of image data could exceed the limit) - in which case you would use appcache, and since you're using it for images you may as well use it for scripts and css - unless there's any significant benefit to loading scripts into localstorage as a seperate affair?

Owner

addyosmani commented Jan 22, 2013

I'll answer on the last point:

We're currently considering expanding basket to handle CSS and other resource types. Technically, there's nothing really stopping us from doing this. The project was originally aiming to just demonstrate script caching benefits over browser cache/other options, however it's possible such features become supported in the near future.

Contributor

sindresorhus commented Jan 22, 2013

is it a case of trading off performance with simplicty that basket.js provides? If thats the case then a tool that automatically generates and manages a manifest file for you can do the same without the performance hit..

Simplicity yes, and being able to define and load dependencies programmatically, instead of having to define a manifest upfront.

We've tried automagic generation of appcache manifest in yeoman, and I didn't really like it, since it will never know all your resources. (more discussion about that here yeoman/yeoman#762).

or is localstorage actually faster than appcache, thus compensating for additional load/parse/execution overhead?

Dunno, I would guess no, but we should make some perf tests prove it either way.

also, images/css - basket js could do these too? Unless theres limitations on the localstorage (eg where a lot of image data could exceed the limit) - in which case you would use appcache, and since you're using it for images you may as well use it for scripts and css - unless there's any significant benefit to loading scripts into localstorage as a seperate affair?

CSS maybe, see #60. Images, no, it would be slow and unnecessary and most likely slow don't page load since localStorage is loaded into the memory from hdd on pageload, would also exceed quota a lot. Images also doesn't block rendering, so I don't see the benefit.


That said, appcache was created to make resources available offline, localStorage as key/value store, and basket.js exploits it for an attempt at improving script loading. One change in the manifest requires all files to be redownloaded. There are benefits and downsides to all of them. Depends on your usage and requirements. We should make an attempt to document these clearly and in what situations you would benefit from using basket.js

Thanks for answering guys, I wasn't sure if I was missing something obvious or (as is the case) it was more of a complex evaluation and sizing up of each.

Even though automagic generation will never know all your resources, nether will localstorage so that's a moot point for comparison - a more programmatic API for appcache would be nice (in fact I think that's already available in browser, but may benefit from some sugar)

Nevertheless I love that basket.js is experimenting and pushing the boundaries of intent, which has always been the true driving force of the web.
I'd love to see a comparative checklist against both

@davidmarkclements AppCache is a douchbag when you try and do it by hand. Don't do it by hand. Find a utility for your stack and you should never have a problem, only drastically lower server costs, and a web app that's as fast as a local app.

localStorage is synchronous but should be asynchronous because disk reads can be really slow, especially if you're not a developer with a SSD. IMO localStorage is best for small pieces of data

Contributor

sindresorhus commented Jan 31, 2013

AppCache is a douchbag when you try and do it by hand. Don't do it by hand. Find a utility for your stack and you should never have a problem, only drastically lower server costs, and a web app that's as fast as a local app.

I'm pretty sure that magical tool doesn't exist though. I encourage you to create it.

IMO localStorage is best for small pieces of data

scripts and css are small pieces of data.

Images are the worst, you can base64 encode them but you're going to still have to hook into the build process to do that.

Those tools do exist, Rack::offline for RoR and of course grunt-contrib-manifest I don't know if they're perfect yet but I'll be hopefully getting to them after another project.

Contributor

sindresorhus commented Jan 31, 2013

Those tools do exist, Rack::offline for RoR and of course grunt-contrib-manifest I don't know if they're perfect yet but I'll be hopefully getting to them after another project.

I dunno, they only help you slightly. The grunt task the least, which really only let's you specify stuff in an object instead of directly into the manifest.

well I guess I'll be making that magically tool sometime ^_^

-Devin http://zerply.com/DevinRhode2
http://zerply.com/devinrhode2

On Thu, Jan 31, 2013 at 2:05 PM, Sindre Sorhus notifications@github.comwrote:

Those tools do exist, Rack::offline for RoR and of course
grunt-contrib-manifest I don't know if they're perfect yet but I'll be
hopefully getting to them after another project.

I dunno, they only help you slightly. The grunt task the least, which
really only let's you specify stuff in an object instead of directly into
the manifest.


Reply to this email directly or view it on GitHubhttps://github.com/addyosmani/basket.js/issues/71#issuecomment-12968590.

Owner

addyosmani commented Jan 31, 2013

To clarify, browser vendors acknowledge that localStorage should ideally be async and there may be work put into changing this behavior in the future. I agree that LS should be for smaller pieces of data, however, from a usability perspective it's easier to use and navigate around the rough-edges than appcache is. We welcome any and all efforts to improve the offline landscape for developers.

@devinrhode2 I think there is a need for such a tool, but I've also created them by hand which for my purposes was fine (small projects, and I didn't do it until clients had stopped asking for changes --- they did in fact ask for changes a few weeks later and that's when I encountered the (anticipated) horrors so a tool would be awesome for larger projects or frequently updating projects.

@addyosmani from a usability perspective for developers, but from a usability perspective for users I would venture that appcache wins (this is why good girls love bad guys) and a nice tidy usable API to mask the woefulness of appcache is certainly on my tooling todo list. Nevertheless, I'm not for discouraging the progress of basket.js either, I believe there's some unique value adding use cases for it (see #75)

Owner

addyosmani commented Jan 31, 2013

Very curious. I hadn't seen asyncStorage before. Something tells me if we were to re-implement this on top of basket.js (i.e using IndexedDB) some people might have a cow :p. It would also have to be done in a way where maximum cross-platform compat was ensured. @sindresorhus wdyt?

Contributor

sindresorhus commented Jan 31, 2013

@addyosmani I'm not sure exactly what you're asking. Can you elaborate?

For Filesystem and IndexedDB. We've discussed it at length before, in the initial conception of Basket.js, but we chose not to go down that path because of various reasons. From what I can remember it was mainly the extremely inconsistent behavior of IndexedDB and the fact the both (pretty sure) asks the user for permission, which is a no go for a generic caching lib.

Owner

addyosmani commented Jan 31, 2013

@sindresorhus I should have elaborated :) I was asking what your thoughts were on the idea of baking asyncStorage support into basket. I've never thought particularly high of IDB and agree with your summary of it being inadequate for a caching lib of this sort.

Contributor

sindresorhus commented Jan 31, 2013

Always happy to review a working prototype, but I have my doubts.

@AlexeyAnshakov AlexeyAnshakov referenced this issue in webRunes/Storage-WRIO-App Feb 21, 2016

Open

Application Cache and LocalStorage #14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment