4 ms·

Sounds interesting. How do you handle that? How do you select the correct/latest ref of each asset to send to the user? It feels like you would have to do the s

Sounds interesting. How do you handle that? How do you select the correct/latest ref of each asset to send to the user? It feels like you would have to do the same amount of work that you would have to do with fingerprinting.

JimDabell 3y ago
With fingerprinting, each asset has a URL you need to ultimately get from your bundler individually. With a URL prefix, your assets retain their original filenames. In some contexts you’ll need to know the prefix, but it’s the same for every asset. And in other contexts you can just use relative URLs and not think about it at all.
- jstummbillig 3y ago
  You would need the correct git hash, no? Instead of /rndotherhash_filename.ext you are looking for /rndgithash/filename.ext I fail to understand how resolving that is simpler.
  - JimDabell 3y ago
    Support you have the following assets: - /js/foo.js - /css/bar.css - /img/baz.png With a content-based hash, end up with something like the following: - /js/foo.abc123.js - /css/bar.def456.css - /img/baz.ghi789.png This means that for each and every asset you have, you need to keep track of their unique filename for that deployment and you need to be able to access that whenever you want to refer to the asset. In practice that means most people rely on their bundler to rewrite every place they refer to those assets, which can make it awkward if they need to refer to them from non-JavaScript contexts. Also in practice, people often seem to ignore anything other than JavaScript or CSS, meaning you get stale assets if they aren’t JavaScript or CSS. With a Git hash prefix, you would have something like: - /abcdef/js/foo.js - /abcdef/css/bar.css - /abcdef/img/baz.png This means you only have one single reference to manage, which you can keep track of without relying on your JavaScript bundler. It also means that in a lot of contexts you don’t need the reference at all, for instance in your stylesheets you can just refer to url(../img/baz.png) and there’s no rewriting necessary to get the right behaviour. Your build process and your infrastructure caching are two separate concerns; it’s easier if they aren’t tightly coupled.
    - idbehold 3y ago
      It might be easier, but it's strictly worse caching since all static assets get invalidated every deployment instead of just the assets which changed.
      - jstummbillig 3y ago
        That would be my objection as well.

JimDabell 3y ago

With fingerprinting, each asset has a URL you need to ultimately get from your bundler individually. With a URL prefix, your assets retain their original filenames. In some contexts you’ll need to know the prefix, but it’s the same for every asset. And in other contexts you can just use relative URLs and not think about it at all.

jstummbillig 3y ago
You would need the correct git hash, no? Instead of /rndotherhash_filename.ext you are looking for /rndgithash/filename.ext I fail to understand how resolving that is simpler.
- JimDabell 3y ago
  Support you have the following assets: - /js/foo.js - /css/bar.css - /img/baz.png With a content-based hash, end up with something like the following: - /js/foo.abc123.js - /css/bar.def456.css - /img/baz.ghi789.png This means that for each and every asset you have, you need to keep track of their unique filename for that deployment and you need to be able to access that whenever you want to refer to the asset. In practice that means most people rely on their bundler to rewrite every place they refer to those assets, which can make it awkward if they need to refer to them from non-JavaScript contexts. Also in practice, people often seem to ignore anything other than JavaScript or CSS, meaning you get stale assets if they aren’t JavaScript or CSS. With a Git hash prefix, you would have something like: - /abcdef/js/foo.js - /abcdef/css/bar.css - /abcdef/img/baz.png This means you only have one single reference to manage, which you can keep track of without relying on your JavaScript bundler. It also means that in a lot of contexts you don’t need the reference at all, for instance in your stylesheets you can just refer to url(../img/baz.png) and there’s no rewriting necessary to get the right behaviour. Your build process and your infrastructure caching are two separate concerns; it’s easier if they aren’t tightly coupled.
  - idbehold 3y ago
    It might be easier, but it's strictly worse caching since all static assets get invalidated every deployment instead of just the assets which changed.
    - jstummbillig 3y ago
      That would be my objection as well.