5 ms·

A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename. Be

A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename. Been doing this for years with infinite (well, practically) cache settings. These days it's built into most js compression tools afaik.

benologist 7y ago
This is the official way to do that I think - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Someone1234 7y ago
That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of raw hashes.
- diggan 7y ago
  You don't necessary need to use a hash based on randomness. Either using the git commit as the version/hash or a hash based on the content of the file itself works. So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since everything is versioned the same way.
  - mattmanser 7y ago
    Git commit is a bad solution, you want to use the file hash so you can have multiple bundles that version automatically. Also, if you pushed a change to even some comments or something not related to code, your bundle will change. Often you have a bundle of library code that you rarely ever push changes to, and you don't want your clients to download each time you make minor changes.
- mattmanser 7y ago
  The file hash of the output file, that's what I meant by hash. Your way has big downsides and is pretty old-fashioned. It's still used by libraries that only have one javascript file, but not by websites that have to have multiple bundles and multiple CSS files. Here's webpack's advice about doing exactly what I'm advocating, it definitely works and is the industry standard: https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/caching/ Firstly, the file hash mechanism is built in to most bundling tools, and the file hash means you never ever, ever, ever get any collisions or make any mistakes or forget to increase the version number. It's all handled automatically in the build process. But on top of that, you can also then also have multiple bundles and they will automatically version themselves on the fly. It's common for most sites to have multiple bundles, meaning when you commit a change and rebuild the site, some of those bundles will not have changed. With the automatic hashing, the browser will only download the bundles that changed and you aren't serving tons of unnecessary javascript. You might have one of rarely changing shared libraries, another of the sales part of the website, another for the client part of the website, another for the admin section, you might have a video player that only parts of the site use, etc. Each release you do would only force the browser to download bundles that actually changed. For example reddit has: https://www.redditstatic.com/_chat.Q8BtxnzGjSI.js https://www.redditstatic.com/crossposting.4zJErPF9qdo.js https://www.redditstatic.com/reddit-init.en.zJ5ikJ21-Gw.js https://www.redditstatic.com/reddit.en.BQfJLVYdPSA.js https://www.redditstatic.com/spoiler-text.vsLMfxcst1g.js Or stackoverflow: https://cdn.sstatic.net/Js/full.en.js?v=b45d5b4c957c https://cdn.sstatic.net/Js/stub.en.js?v=963cc3083a37 https://clc.stackoverflow.com/markup.js?omni=Ak4r5CHnPNcIR2AAAAAAAAACAAAAAQAAAAMAAAAAAKpYlh7uXVCYJKM&zc=24%3B4&pf=0&lw=165 Or stackoverflow's CSS: https://cdn.sstatic.net/Shared/stacks.css?v=897466c4b64a https://cdn.sstatic.net/Sites/stackoverflow/primary.css?v=2d33230dde3d See how they have a "shared" css they use on all the stackexchange sites, and a "stackoverflow" one, and that they can release each without destroying the cached version of the other?
  - Someone1234 7y ago
    You're talking about something entirely differently than what I am talking about. We aren't bundling at all. We're minifying and relying on H2 for high performance concurrent delivery. Bundling is the only old-fashioned thing here. Semantic versioning is timeless. You're talking about a mechanism that is purely designed to cache-bust. I am talking about a mechanism for humans to deploy, understand, and utilize libraries across teams (and to group different files into distinct versions). Apples and oranges. The thread was about architecture, after all... I won't get drawn too far into your post since it has too many strongly held claims without explanation/justification and I don't feel like trying to unravel that. But, yes, if you're automatically generating bundles for HTTP 1.1, append a hash. We aren't, so we don't.

benologist 7y ago

This is the official way to do that I think - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Someone1234 7y ago

That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of raw hashes.

diggan 7y ago
You don't necessary need to use a hash based on randomness. Either using the git commit as the version/hash or a hash based on the content of the file itself works. So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since everything is versioned the same way.
- mattmanser 7y ago
  Git commit is a bad solution, you want to use the file hash so you can have multiple bundles that version automatically. Also, if you pushed a change to even some comments or something not related to code, your bundle will change. Often you have a bundle of library code that you rarely ever push changes to, and you don't want your clients to download each time you make minor changes.
mattmanser 7y ago
The file hash of the output file, that's what I meant by hash. Your way has big downsides and is pretty old-fashioned. It's still used by libraries that only have one javascript file, but not by websites that have to have multiple bundles and multiple CSS files. Here's webpack's advice about doing exactly what I'm advocating, it definitely works and is the industry standard: https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/caching/ Firstly, the file hash mechanism is built in to most bundling tools, and the file hash means you never ever, ever, ever get any collisions or make any mistakes or forget to increase the version number. It's all handled automatically in the build process. But on top of that, you can also then also have multiple bundles and they will automatically version themselves on the fly. It's common for most sites to have multiple bundles, meaning when you commit a change and rebuild the site, some of those bundles will not have changed. With the automatic hashing, the browser will only download the bundles that changed and you aren't serving tons of unnecessary javascript. You might have one of rarely changing shared libraries, another of the sales part of the website, another for the client part of the website, another for the admin section, you might have a video player that only parts of the site use, etc. Each release you do would only force the browser to download bundles that actually changed. For example reddit has: https://www.redditstatic.com/_chat.Q8BtxnzGjSI.js https://www.redditstatic.com/crossposting.4zJErPF9qdo.js https://www.redditstatic.com/reddit-init.en.zJ5ikJ21-Gw.js https://www.redditstatic.com/reddit.en.BQfJLVYdPSA.js https://www.redditstatic.com/spoiler-text.vsLMfxcst1g.js Or stackoverflow: https://cdn.sstatic.net/Js/full.en.js?v=b45d5b4c957c https://cdn.sstatic.net/Js/stub.en.js?v=963cc3083a37 https://clc.stackoverflow.com/markup.js?omni=Ak4r5CHnPNcIR2AAAAAAAAACAAAAAQAAAAMAAAAAAKpYlh7uXVCYJKM&zc=24%3B4&pf=0&lw=165 Or stackoverflow's CSS: https://cdn.sstatic.net/Shared/stacks.css?v=897466c4b64a https://cdn.sstatic.net/Sites/stackoverflow/primary.css?v=2d33230dde3d See how they have a "shared" css they use on all the stackexchange sites, and a "stackoverflow" one, and that they can release each without destroying the cached version of the other?
- Someone1234 7y ago
  You're talking about something entirely differently than what I am talking about. We aren't bundling at all. We're minifying and relying on H2 for high performance concurrent delivery. Bundling is the only old-fashioned thing here. Semantic versioning is timeless. You're talking about a mechanism that is purely designed to cache-bust. I am talking about a mechanism for humans to deploy, understand, and utilize libraries across teams (and to group different files into distinct versions). Apples and oranges. The thread was about architecture, after all... I won't get drawn too far into your post since it has too many strongly held claims without explanation/justification and I don't feel like trying to unravel that. But, yes, if you're automatically generating bundles for HTTP 1.1, append a hash. We aren't, so we don't.