Cache and Prizes - Infrequently Noted
The idea of the browser pre-caching heavily used JS libraries is an attractive nuisance: looks good, probably won't work. Is there a workable version of this idea? What would the constraints on it be? Could it ever be effective and fair? Down the rabbit hole we go.
If you work on a browser, you will often hear remarks like, Why don't you just put [popular framework] in the browser? This is a good question — or at least it illuminates how browser teams think about tradeoffs. Spoiler: it's gnarly. Before we get into it, let's make the subtext of the proposal explicit: Libraries provided this way will be as secure and privacy-preserving as every other browser-provided API. Browsers will cache tools popular among vocal, leading-edge developers . There's plenty of space for caching the most popular frameworks. Developers won't need to do work to realise a ben
Explore this link on the map →related reading
- This Page is Designed to Last: A Manifesto for Preserving Content on the Webjeffhuang.com
- Code caching for JavaScript developers · V8v8.dev
- Internet Computers - Not Boring by Packy McCormicknotboring.co
- pketh.orgpketh.org
- Service worker overview | Workbox | Chrome for Developersdeveloper.chrome.com
- HTTP caching - HTTP | MDNdeveloper.mozilla.org
- The Market for Lemons - Infrequently Notedinfrequently.org
- Disk Cachechromium.org
- Navigating the future of frontendfrontendmastery.com
- The new wave of Javascript web frameworksfrontendmastery.com
- Populating the page: how browsers work - Performance | MDNdeveloper.mozilla.org
- workbox-precaching | Modules | Chrome for Developersdeveloper.chrome.com