6 ms·

Maybe it's time for browsers to go beyond the cache concept and implement a common standard package manager. Download once, stay forever. True immutable. As de

Maybe it's time for browsers to go beyond the cache concept and implement a common standard package manager. Download once, stay forever. True immutable. As developers, we try everyday to squeeze till the last byte and optimize things. We all know how performance is important. So why download for every website the same asset: React, jQuery, libraries, CSS utils, you-name-it? What a waste!

notatoad 10y ago
How is your proposal different to what's happening here? If two websites call a library from the same CDN that implements immutable, then isn't that just a distributed package manager with URL-based namespacing?
- achairapart 10y ago
  The problem will be that every website should use the same CDN. Not likely to happen and centralize things is never good. You'll also miss other features: version range alone could save tons of bandwidth.
  - notatoad 10y ago
    >centralize things is never good. but centralizing in the browser is?
vvggff 10y ago
Yeah, you know it so much that I have to download 100s of MBs to view a text-only site.
- achairapart 10y ago
  Why that? The browser download only the assets you require.
Orangeair 10y ago
Shouldn't using common CDNs solve this problem?
- achairapart 10y ago
  I think they are more like a band-aid than a solution.
- acdha 10y ago
  Using CDNs lowers the hit rate because the average user's browser cache will have each library stored number of CDNs times the number of versions in widespread usage. A package manager could improve some of this by allowing you to say “Any version of jQuery between 1.0 and 2.0 is fine” when most sites don't depend on point releases. The Subresource Integrity spec for strong content hashes could improve cache hits by allowing a different URL to be used if the hash matches but everyone wants to avoid that turning into a massive security / privacy hit — see e.g. https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...
  - px1999 10y ago
    I understand the idea of supporting ranges of libraries from a development perspective, but when you're running something in production, is "use any of these configurations" ever desirable? Presumably there's a reason that you'd _want_ them to use 1.12.4 over 1.0.0 (or you'd want to at least check that they didn't break anything that you rely on in 1.13 when that comes out)?
    - acdha 10y ago
      It's desirable if you're really focused on performance – if you're not a site like Google/Facebook which people access all the time, it's safe to assume that none of your resources are cached and so you might find n milliseconds of load time a healthy gain (less so now that HTTP/2 is widespread). In many cases it's more likely that you'd know of a bug fixed in a new release – where you'd say libfoo >= 1.12.4 – than that 1.3 has a huge problem.
rwmj 10y ago
Powered by a content-addressable cache, where each object is identified by the hash of its content only: https://rwmj.wordpress.com/2013/09/09/half-baked-idea-content-addressable-web-proxy/#content https://rwmj.wordpress.com/2013/09/09/half-baked-idea-conten...
- niftich 10y ago
  In a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]: The problem is that www.victim.com/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it. [1] https://news.ycombinator.com/item?id=10310594 https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333 https://news.ycombinator.com/item?id=10312333
  - tetrep 10y ago
    This is fixed by relying on CORS and using a key of (domain, hash) rather than just the hash.
    - woogley 10y ago
      But then you're still downloading jQuery (or whatever) again for every unique domain
      - d33 10y ago
        Not if it points to a CDN.
        woogley 10y ago
        This brings us back to current status, as it defeats the purpose of normalizing arbitrary CDNs with the hash
grashalm01 10y ago
Great. By compromising one package you can access their bank account...
- hueving 10y ago
  Same thing as compromising one of these packages loaded from a CDN... If someone loads a bad JS library, it doesn't matter where it came from.
jonchang 10y ago
Decentraleyes for Firefox helps with this issue, it's a script cache for CDN assets like jQuery: https://github.com/Synzvato/decentraleyes/wiki/Simple-Introduction https://github.com/Synzvato/decentraleyes/wiki/Simple-Introd...
benjaminjackman 10y ago
We don't need to have anything as complex as package manager. It would be much easier to just link to these libraries (and any other resource) by the hash of their content. If you do that you would just have to link to resources by their content hash. I'm not really sure why this isn't already in place. edit: The reason I'm not sure why because it sure seems to me that multiple threads on the post are all suggesting basically the same simple idea, the ability to serve a file by it's hash (either just by it's hash alone, or by a url + the hash). Personally, I think whatever form these url's take i think it ought to be backward compatible which I think is possible.
- achairapart 10y ago
  > We don't need to have anything as complex as package manager. Maybe you're right. But still, today we need very complex build tools and silly server hacks like setting expire headers in 10 years. I wish instead it was as simple as deploying my 3kb app.js and tell the browser: "Hello there, here's my manifest with all the dependecies I need to run my app. Thank you.".
- taeric 10y ago
  Linking by hash to all common resources would be bad. You do want fixes and updates, after all.
  - jacobsenscott 10y ago
    Links are already tied to some specific version. Nobody serves "jquery.js" that points to a constantly updated version of jquery. Nobody that's sane anyway.
    - taeric 10y ago
      Fair. My point was more that for many resources, you probably do appreciate this. Certainly package managers do this. Not sure why web would be different.
- paulddraper 10y ago
ComodoHacker 10y ago
I expect WebAssembly to handle this.
deleted 10y ago
[deleted]
gambler 10y ago
The fact that this architecturally clueless comment is at the top for an article about caching makes me wheep for the future of the web. Packages inevitably create a tangle of complex problems that page/document model avoids. That is one of the main reasons web apps replaced normal apps in so many domains. Not to mention that a package system will give a huge competitive advantage to already popular scripts, which will inevitably lead to technological stagnation. And it will remove the biggest disincentive to avoid bloat.

notatoad 10y ago

How is your proposal different to what's happening here? If two websites call a library from the same CDN that implements immutable, then isn't that just a distributed package manager with URL-based namespacing?

achairapart 10y ago
The problem will be that every website should use the same CDN. Not likely to happen and centralize things is never good. You'll also miss other features: version range alone could save tons of bandwidth.
- notatoad 10y ago
  >centralize things is never good. but centralizing in the browser is?

vvggff 10y ago

Yeah, you know it so much that I have to download 100s of MBs to view a text-only site.

achairapart 10y ago
Why that? The browser download only the assets you require.

Orangeair 10y ago

Shouldn't using common CDNs solve this problem?

achairapart 10y ago
I think they are more like a band-aid than a solution.
acdha 10y ago
Using CDNs lowers the hit rate because the average user's browser cache will have each library stored number of CDNs times the number of versions in widespread usage. A package manager could improve some of this by allowing you to say “Any version of jQuery between 1.0 and 2.0 is fine” when most sites don't depend on point releases. The Subresource Integrity spec for strong content hashes could improve cache hits by allowing a different URL to be used if the hash matches but everyone wants to avoid that turning into a massive security / privacy hit — see e.g. https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...
- px1999 10y ago
  I understand the idea of supporting ranges of libraries from a development perspective, but when you're running something in production, is "use any of these configurations" ever desirable? Presumably there's a reason that you'd _want_ them to use 1.12.4 over 1.0.0 (or you'd want to at least check that they didn't break anything that you rely on in 1.13 when that comes out)?
  - acdha 10y ago
    It's desirable if you're really focused on performance – if you're not a site like Google/Facebook which people access all the time, it's safe to assume that none of your resources are cached and so you might find n milliseconds of load time a healthy gain (less so now that HTTP/2 is widespread). In many cases it's more likely that you'd know of a bug fixed in a new release – where you'd say libfoo >= 1.12.4 – than that 1.3 has a huge problem.

rwmj 10y ago

Powered by a content-addressable cache, where each object is identified by the hash of its content only: https://rwmj.wordpress.com/2013/09/09/half-baked-idea-content-addressable-web-proxy/#content https://rwmj.wordpress.com/2013/09/09/half-baked-idea-conten...

niftich 10y ago
In a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]: The problem is that www.victim.com/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it. [1] https://news.ycombinator.com/item?id=10310594 https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333 https://news.ycombinator.com/item?id=10312333
- tetrep 10y ago
  This is fixed by relying on CORS and using a key of (domain, hash) rather than just the hash.
  - woogley 10y ago
    But then you're still downloading jQuery (or whatever) again for every unique domain
    - d33 10y ago
      Not if it points to a CDN.
      - woogley 10y ago
        This brings us back to current status, as it defeats the purpose of normalizing arbitrary CDNs with the hash

grashalm01 10y ago

Great. By compromising one package you can access their bank account...

hueving 10y ago
Same thing as compromising one of these packages loaded from a CDN... If someone loads a bad JS library, it doesn't matter where it came from.

jonchang 10y ago

Decentraleyes for Firefox helps with this issue, it's a script cache for CDN assets like jQuery: https://github.com/Synzvato/decentraleyes/wiki/Simple-Introduction https://github.com/Synzvato/decentraleyes/wiki/Simple-Introd...

benjaminjackman 10y ago

We don't need to have anything as complex as package manager. It would be much easier to just link to these libraries (and any other resource) by the hash of their content. If you do that you would just have to link to resources by their content hash. I'm not really sure why this isn't already in place. edit: The reason I'm not sure why because it sure seems to me that multiple threads on the post are all suggesting basically the same simple idea, the ability to serve a file by it's hash (either just by it's hash alone, or by a url + the hash). Personally, I think whatever form these url's take i think it ought to be backward compatible which I think is possible.

achairapart 10y ago
> We don't need to have anything as complex as package manager. Maybe you're right. But still, today we need very complex build tools and silly server hacks like setting expire headers in 10 years. I wish instead it was as simple as deploying my 3kb app.js and tell the browser: "Hello there, here's my manifest with all the dependecies I need to run my app. Thank you.".
taeric 10y ago
Linking by hash to all common resources would be bad. You do want fixes and updates, after all.
- jacobsenscott 10y ago
  Links are already tied to some specific version. Nobody serves "jquery.js" that points to a constantly updated version of jquery. Nobody that's sane anyway.
  - taeric 10y ago
    Fair. My point was more that for many resources, you probably do appreciate this. Certainly package managers do this. Not sure why web would be different.
paulddraper 10y ago

ComodoHacker 10y ago

I expect WebAssembly to handle this.

deleted 10y ago

[deleted]

gambler 10y ago

The fact that this architecturally clueless comment is at the top for an article about caching makes me wheep for the future of the web. Packages inevitably create a tangle of complex problems that page/document model avoids. That is one of the main reasons web apps replaced normal apps in so many domains. Not to mention that a package system will give a huge competitive advantage to already popular scripts, which will inevitably lead to technological stagnation. And it will remove the biggest disincentive to avoid bloat.