This is not an officially supported Google product.
This repository is used to coordinate the work of the progressive fetching discussion group. Anybody interested in joining can do so by creating a pull request adding themselves to the Members section below.
Most discussions happen in the open within the issues of this repository.
Meeting notes will be made available in the docs/meetings directory.
Progressive fetching refers to the idea that applications should fetch only the minimum amount of code necessary at the time, loading additional code on demand as the user interacts with the app. An architecture that supports this behavior needs to meet the following requirements:
- The application or framework DX supports adequate (and natural) seams for code splitting, and lazy / staggered fetching.
- The build system supports effective and fine-grained code splitting, including handling of experimental variants.
- Both client and server runtime support determining the minimum needed code and data for current conditions and fetching it from the asset host.
- It must be compatible with arbitrary existing 3rd-party npm dependencies that many apps in the ecosystem depend on.
Beyond what is under the control of the application owners, there may also be web platform primitives around serving that may need to be created in the service of this kind of architecture. Neither serving raw ES modules nor traditional static bundles generated by typical webpack setups work well enough. Today we have lots of existing and proposed primitives (eg. es-modules, HTML modules, CSS modules, JSON modules, web-packaging, bundled exchange) and yet inadequate serving support.
Reduce the cost of adopting progressive fetching and help highlight use cases where it provides value.
- Collect and document use cases, best practices, and trade-offs around building and serving code on the web.
- Make it easy to set up and use progressive fetching, including adoption in existing projects.
- Focus on incremental results that can be integrated quickly. We want to converge onto one solution instead of creating yet-another solution.
- Build on the existing ecosystem of tools where possible.
- Create interfaces that allow composition of different tools. E.g. it should be possible to build a serving solution without deep knowledge of the build toolchain or the runtime.
- Create a reference implementation of dynamic bundling that handles both JS and CSS code and supports Google-scale deployments.
- Work in the open for all discussions and decisions. Interested parties can join at any time. Favor offline channels like docs and issue threads over online channels like meetings.
- @fenghaolw - Hao Feng
- @jkrems - Jan Krems