Hacker News Reader

Comment by anderspitman | Hacker News Reader

As of the last couple years, Chrome is the web. The writing has been on the wall since at least Widevine. The browser wars are over, and I don't see any scrappy startup crossing the moat of complexity GOOG has built around "modern" browsers. Especially when combined with their stranglehold of the standards committees. We need to find a new attack vector.

View on HN

They’ll do it to themselves.

One thing I see regularly is Chrome’s web caching being so aggressive it is driving front-end developers to start using FF for dev.

We simply need to stand back and let time take its course.

Does Chrome no longer have the option to disable cache while dev tools is open?

It does have it. I personally often use Firefox for the css grid and flexbox tools but they're very similar in functionality.

A product owner I worked with around 2016 regularly had problems with this, eventually we figured out whenever this happened the only way to clear her cache was to open dev tools, long-press reload, and pick the 3rd option (it only showed up when dev tools were open).

It sure does and it works, not sure how or what use case the parent has problems with. Would be quite interesting to find out.

Not the parent, but I have run into these ones before:

Issue 645845 (Open, ~4 years old): DevTools: "disable cache" doesn't work for media resources: https://bugs.chromium.org/p/chromium/issues/detail?id=645845

Issue 470030 (WontFix): 'Disable cache' should prevent HSTS redirects: https://bugs.chromium.org/p/chromium/issues/detail?id=574345

Issue 775435 (Fixed after ~1 year): Disable cache does not disable cached redirects https://bugs.chromium.org/p/chromium/issues/detail?id=775435

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.

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.

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.

... 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.

... 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.

Things looked similar amid the dominance of IE. I think it will probably happen eventually, though you're right that a start-up probably won't do it. The problem that no one pays for web browsers. There are companies building alternative engines for commercial embedding (including one that's parallel and very fast), so it would probably involve one of those being open-sourced.

Reply on news.ycombinator.com