Hacker News new | past | comments | ask | show | jobs | submit login

For anyone asking what this means in numbers:

> The overall cache miss rate increases by about 3.6%, changes to the FCP (First Contentful Paint) are modest (~0.3%), and the overall fraction of bytes loaded from the network increases by around 4%. You can learn more about the impact on performance in the HTTP cache partitioning explainer. [0]

[0]: https://developers.google.com/web/updates/2020/10/http-cache...

Additional metrics: https://github.com/shivanigithub/http-cache-partitioning#imp...




This is an incredibly problematic number to report, bordering downright deceitful, because it ignores that we have not been able to use CDNs (because we have had to bundle our many JS files together, first for CommonJS, then for an ES-Module 1.0 specification with fixed/non-modular import addresses). But just recently, we have finally begun to pay off the technical debt to let us once more build web pages that use many different JS files from CDNs[1]. We are finally emerging from this long dark sad road to return to the glory of using CDNs that can cache our assets for us, let us share widely across the web.

And just just just before ES Modules finally get good & modular & helpful, we destroy the shared cache that would have made them helpful. We have been on this voyage for 10 years, starting from the pre-modules but cached days, through the long dark & violent seas of modules-but-no-caching, to finally finally get to modules-that-cache-well. We finally have standards & tools in place that would allow us to begin to cache modules effectively, across sites. Except no, not any more.

Whatever numbers you see for this, they are lies. They don't represent any honest truth. They portray only a poor reflection of a bad place that we have been desperate to escape from. We have wanted to cache modules effectively with CDNs for years, but ES Modules had not been suitable to the task. To judge the impact based only on what we can see, without projecting to what the web we were all trying to make happen: that's incredibly sad. We'll never know. All possibility is being chopped off and cut down. This is an incredibly sad, incredibly tragic culmination to a long long struggle to make the web better, and frankly, I am disappointed beyond words that the teams have taken such an aggressive change of defaults so casually for such minimal proven harm. If there is a real security issue here, it should have been dealt with via more Content Security Policy flags, not by unweaving the web & making each site have it's own view of the world, unique from every other site. The security atmosphere is paranoid & delusional, & nothing tops their inquest for absolute security.

[1] https://www.bryanbraun.com/2020/10/23/es-modules-in-producti...


Admittedly Content Security Policy is not enough. It's not site's assets being protected here.

We are protecting users from sites coordinating their actions via the presence of resources. If I visit store.example they might cache a /big-spender resource. Then if I visit other.example, they can check to see if I have /big-spender cached.

As a user, I ought to be protected against coordinated tracking mechanisms like this. Content Security Policy might be able to let store.example protect it's asset, but in this case, the problem is that store.example might be deliberately exposing the cached/not-cached state of that resource to others; it is the user, not the site's content, that needs to be secured.

Thusfar the only safe we've found to do it is to have every site have it's own naive, isolated, alone view of the world. This is, alas, in my perspective, extremely unfortunate. I picture the spider web of information being cut into pieces, broken apart. But I also recognize the necessity of this. I can't stand it, but I see no alternatives. And makes me so sad that we will never ever see modules work on the web. That ~2011 was the last & will forever be the last good year for CDNs, before CommonJS & bundling took over, before we made CDNs no longer places of sharing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: