4 ms·

Oh, it's fine keeping the development tools open for local dev, but then it seems like developers (usually more junior) will get spooked when they open the appl

Oh, it's fine keeping the development tools open for local dev, but then it seems like developers (usually more junior) will get spooked when they open the application in a new tab, loading from the test server, and their changes appear to not have been built out, or only half built out. It causes some confusion, and I often need to remind others that if they are using Chrome, to please clear their cache. The other thing that I should have mentioned is with non-dev staff. When new builds and updates get pushed out, they often have problems because of Chrome's aggressive caching. This group isn't as privy to knowing about developer tools and chaching, and it is highly frustrating and annoying for them. It seems like they will still use Chrome for casual browsing, but then start to use Firefox or Safari for testing builds. I use Firefox 100% of the time and very very rarely have these kinds of issues. All I can say is that something is seriously wrong with Chrome's caching policy, from a UX perspective. People do get frustrated in ways that they don't when using Safari or Firefox.

foota 6y ago
I mean, to some degree you need to take advantage of build options that put out resources under unique paths, which I'm fairly certain is standard guidance by now.
- rangoon626 6y ago
  Yes, I should implement scorched-earth cache busting and force a complete reload of all bundles, because one craptastic browser relies on aggressive caching so that their complimentary ad services doesn’t bog down website performance. That’s exactly how the web should be.
  - foota 6y ago
    ... Yes? I mean, if you're not whole into the js ecosystem you can just use a cache buster parameter on your js requests in development, but I think the recommended approach is to use module splitting so that parts of the bundle that don't change remain the same. Alternatively if you just hate caching you can set cache control headers on your js. I think tying caching behavior to Google's web sites is silly, caching is a crucial part of performance for any heavy web application.
    - rangoon626 6y ago
      ... No. Every other browser seems to find a sane middle ground. Anyway this was never about my own practices, this was about how Chrome has become annoying and how it will result in attrition. The faster this happens, the better.

foota 6y ago

I mean, to some degree you need to take advantage of build options that put out resources under unique paths, which I'm fairly certain is standard guidance by now.

rangoon626 6y ago
Yes, I should implement scorched-earth cache busting and force a complete reload of all bundles, because one craptastic browser relies on aggressive caching so that their complimentary ad services doesn’t bog down website performance. That’s exactly how the web should be.
- foota 6y ago
  ... Yes? I mean, if you're not whole into the js ecosystem you can just use a cache buster parameter on your js requests in development, but I think the recommended approach is to use module splitting so that parts of the bundle that don't change remain the same. Alternatively if you just hate caching you can set cache control headers on your js. I think tying caching behavior to Google's web sites is silly, caching is a crucial part of performance for any heavy web application.
  - rangoon626 6y ago
    ... No. Every other browser seems to find a sane middle ground. Anyway this was never about my own practices, this was about how Chrome has become annoying and how it will result in attrition. The faster this happens, the better.