Accelerating the adoption of modern web features, and migrating away from outdated approaches

• Past
• Confirmed
• Breakout Sessions

The web platform's evolution is often faster than developer practices. This lag creates a two-part problem that slows the adoption of modern APIs and leaves unnecessary bloat on the web:

1. The "sticky polyfill" problem: A feature (e.g., IntersectionObserver) becomes Baseline, but developers continue to ship unnecessary polyfills and fallbacks for it, sometimes for years. The IntersectionObserver polyfill, for example, still gets over 2.1 million weekly downloads despite the feature being Baseline for over 6.5 years.

2. The "reluctant adoption" problem: A new, powerful feature (e.g., the Scheduler API) is available, but because it is not yet Baseline, developers may be reluctant to use it, even when robust polyfills and fallback strategies exist. Those strategies should be easily discoverable to developers and integrated with their tools.

Both problems hold back the web and share a common root: the lack of a structured, machine-readable data source that maps "old ways" (specific polyfill packages, legacy patterns) to their "new way" modern API counterparts.

This session proposes we create one.

If tooling (IDEs, linters, framework CLIs, browser DevTools) had a "Rosetta Stone" dataset, it could, for example:

• Detect the IntersectionObserver polyfill, query this dataset, see the native API is Baseline, and confidently recommend removing the polyfill.
• See a use case for the Scheduler API, query the dataset, and suggest a progressive enhancement strategy that safely encourages immediate adoption.

Agenda

Chairs:
Rick Viscomi, François Daoust, Kadir Topal

Description:
The web platform's evolution is often faster than developer practices. This lag creates a two-part problem that slows the adoption of modern APIs and leaves unnecessary bloat on the web:

1. The "sticky polyfill" problem: A feature (e.g., IntersectionObserver) becomes Baseline, but developers continue to ship unnecessary polyfills and fallbacks for it, sometimes for years. The IntersectionObserver polyfill, for example, still gets over 2.1 million weekly downloads despite the feature being Baseline for over 6.5 years.

2. The "reluctant adoption" problem: A new, powerful feature (e.g., the Scheduler API) is available, but because it is not yet Baseline, developers may be reluctant to use it, even when robust polyfills and fallback strategies exist. Those strategies should be easily discoverable to developers and integrated with their tools.

Both problems hold back the web and share a common root: the lack of a structured, machine-readable data source that maps "old ways" (specific polyfill packages, legacy patterns) to their "new way" modern API counterparts.

This session proposes we create one.

If tooling (IDEs, linters, framework CLIs, browser DevTools) had a "Rosetta Stone" dataset, it could, for example:

• Detect the IntersectionObserver polyfill, query this dataset, see the native API is Baseline, and confidently recommend removing the polyfill.
• See a use case for the Scheduler API, query the dataset, and suggest a progressive enhancement strategy that safely encourages immediate adoption.

Goal(s):
This session is a working discussion to brainstorm this dataset: what it should contain, where it could live, and how we can collaborate to build and maintain it to accelerate the entire web forward.

Materials:

• Session proposal on GitHub

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

• Download as ics