和浏览器缓存相比的优势是什么？

[ZheFeng]

我在浏览器里的缓存不就已经足够了吗？

我能想到的是这样做可以避免用户清除缓存。请问还有其他优势吗？

相信作者肯定是有原因做这个的，这样问只是希望更清晰的了解，从而能更好的推广。

另外又想到一个，就是既然代码是以string的状态存在浏览器，是不是会考虑在代码升级时只加载更新的部分，这样就比浏览器缓存优势大多了。

可是如果是考虑代码升级，那其实还是很复杂的，这个库并没有解决真正核心的问题呀。求解答。谢谢

[Brooooooklyn]

http://zhihu.com/question/28467444/answer/41148739
ls 和本地缓存比毫无优势。不过可能(没有做过测试)在弱网的移动设备上有点优势

[classicemi]

关于这个问题以及以后要做的事情，中文文档里更新了 FAQ 部分可以看下。
https://elemefe.github.io/bowl/zh-cn

[ZheFeng]

看了更新的FAQ

浏览器的缓存并不可靠，用户有可能关闭缓存或手动清除缓存，另外即使有缓存每次还是要向服务器发送请求确认资源是否过期，bowl 可以完全控制这一环节，也不会发送任何请求。

其中对于

缓存每次还是要向服务器发送请求确认资源是否过期

并不认同，你看我的截图就知道是不向服务器发请求的，这个是可以控制的。截图里显示延迟是 0ms。

[classicemi]

@ZheFeng
根据你的截图，from memory cache 表示的是资源命中了强缓存这是根据资源的 http header 来判断的，包括 Expires 和 Cache-Control 这两种 header，在这种情况下，浏览器缓存的效果是最好的，都没有之一。
需要发送请求确认资源是否过期的是协商缓存，是另一种浏览器缓存，相比于强缓存，受客户端缓存未及时更新的影响较小（因为毕竟要向服务器确认一次），所以它的应用更灵活一点，我在 FAQ 中指的实际上是这种缓存方式，没有说清楚和强缓存的区别，是我的疏忽。
就像上面的回复提到的一样，利用 LS 缓存有它的局限性，也有它的优势，从目前的情况来看确实优势并不明显，但这里更多的是对使用这种思路来做缓存的一个探索，后面会给 bowl 增加更多实用的功能，不会只局限于简单的 LS 缓存。

[ZheFeng]

@classicemi 谢谢，强烈支持这个勇于探索的精神。

并且利用LS对于代码升级，版本迭代会有非常好的效果。这种探索是很有实际意义的。

[Brooooooklyn]

@classicemi 可以参考一下 https://github.com/mtjs/mt
我觉得相对于功能上对标浏览器缓存与 http 304， 增量更新 才是真正的杀手级的 feature。毕竟 浏览器缓存失效 与 用户清空 缓存都只能算是 edge case，而增量更新则是目前前端生态普遍的需求。

[ZheFeng]

+1

[classicemi]

@Brooooooklyn 谢谢，很有参考价值，这方面已经着手在做了