The future of JavaScript modules: JS module blocks and native bundling
summary
Two specific proposals aim to cut network and IPC overhead: JS module blocks (stage 1) let a module literal be passed to a Worker so parallel code runs without a separate file and module blocks do not close over outer scopes; resource bundle preloading supplies a binary map of URLs to payloads where the server returns only the subset missing from cache and the browser inserts each entry into the HTTP cache. Privacy rules include uncredentialed bundle requests and URL-by-URL enforcement; tooling and test implementations (bundlers, servers, CDNs) are required to validate the performance claims.
AI-written summary · about
chapters (15)
- 0:00Start
- 7:09What Are Multiple Blocks
- 19:08Loading Performance Factors
- 19:22The Trade-Offs between Individual Resources and Current Bundlers
- 20:11Resource Overhead
- 20:58Inter-Process Communication
- 23:09Parallel Processing
- 25:34Waterfall Bundling
- 26:59Compression
- 28:14Caching
- 30:03Privacy
- 30:22Privacy Concerns
- 33:58Content Blocking
- 36:26Content Blocking Efficiency
- 38:52Stability
related talks
46mES Modules: The next revolution?
36mES6 Modules & HTTP/2 - Will We Stop Packaging Our JavaScript Code?
28mPast, Present, and Future
27mA novel, efficient approach to JavaScript loading
35mBrowser Package Management
36mUnbundling the JavaScript module bundler
41mThe future is modules not frameworks. JS modules Architecture demo.
37mModules for JS.next