Can Angular Provide a Way to Guarantee Support for a Broader Range of Browsers?

[kakao-fleek-moon]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

Hello Angular team,
First of all, thank you for your continued work on improving the framework. While upgrading our large-scale application to Angular 20, we encountered some questions and limitations related to browser support that we would like to clarify and formally request enhancements for.

✅ Facts

• Our service officially supports Chrome ≥ 67 and iOS ≥ 14,
  and our Browserslist configuration has been aligned with these requirements.

• Up through Angular 18, this setup worked without issues.

• After upgrading to Angular 20, running the development server now triggers Unsupported Browsers warnings whenever our configured browsers fall below Angular’s Baseline requirement.

• Reviewing Angular CLI source code indicates that Angular does not ignore our Browserslist settings. Instead, Angular compares them to the new Baseline and emits warnings when they do not meet the threshold.

• We already operate a Babel + core-js polyfill pipeline, which ensures that Chrome 67 and iOS 14 work properly in our production environment.

⸻

？ Questions / unclear points in the documentation

1. Before Angular 20, Angular followed a “latest two major versions” support model. With Angular 20 adopting the “widely available Baseline,” it is unclear whether this change:
   • effectively reduces the supported browser range, or
   • simply standardizes the criteria without reducing actual support. The documentation does not clearly explain this transition.

2. We would like to know whether Angular 20 introduces any significant ES or language-level changes that justify meaningfully raising the minimum browser requirements relative to Angular 18.

3. Our application is extremely large-scale (over 1 million lines of Angular code) and must support over 99% of users, including those on older browsers.Since we already use a custom Babel + core-js polyfill pipeline, we want to know whether Angular can provide official mechanisms that:
   • allow broader or lower browser targets, and
   • support custom polyfill strategies for teams that require extended browser compatibility.

Proposed solution

Provide an official “extended polyfill mode”

This mode could offer:
• Automatic polyfill determination based on Browserslist
• Native integration of core-js within Angular’s build pipeline
• The ability for applications to opt in to supporting browsers below Angular’s Baseline

Example:

{
  "polyfillMode": "extended"
}

Alternatives considered

[alan-agius4]

Hello, Thank you for the detailed report.

Browser Vendor Support Status

Before addressing the Angular-specific questions, it is critical to highlight the status of the browsers you are targeting.

You mentioned supporting Chrome 67 and iOS 14. These versions are no longer actively supported by the Chrome and WebKit (Apple) teams respectively.

• Chrome 67: Released in May 2018. Google provides security updates only for the latest stable release (and occasionally the immediate prior version). A browser from 2018 contains unpatched security vulnerabilities and lacks modern TLS standard support.
• iOS 14: Released in 2020. Apple generally ceases security updates for an iOS major version once the version two generations ahead is established. With iOS 18 currently in circulation, iOS 14 is considered End-of-Life (EOL) and unsafe for end-users.

While we understand enterprise requirements often lag behind consumer trends, Angular's support policy attempts to balance broad reach with the ability to use secure, performant web standards.

The Shift to "Baseline"

With recent versions, Angular has aligned its browser support strategy with Baseline. This initiative (supported by Google, Mozilla, Apple, and Microsoft) defines features that are "Widely Available" across all major engines.

You can view the exact versions supported for your Angular version here:
https://angular.dev/reference/versions#browser-support

To answer your specific questions regarding this transition:

1. Clarifying the Support Model Change

Is this effectively reducing support or simply standardizing it?

It is primarily a standardization, but for "long-tail" legacy browsers, it effectively reduces official support. The "latest two major versions" model was ambiguous (e.g., Safari releases major versions annually, Chrome monthly).

Adopting Baseline Widely Available provides a concrete technical threshold: a feature is widely available generally 30 months after it lands in all major interoperable browsers. If Chrome 67 falls outside this window (which it does), it is flagged as unsupported because the maintenance burden to shim the delta between Baseline and 2018-era web standards is prohibitive for the core framework.

2. Technical Justification for Raising Requirements

Does Angular 20 introduce changes that justify raising requirements?

Yes. The shift allows us to drop significant legacy weight and leverage the platform:

• Native Async/Await: We are moving away from Zone.js towards Zoneless change detection (Signals). This relies heavily on native async/await and how the microtask queue handles promises natively. Heavily polyfilled async behavior often behaves subtly differently than native implementations, leading to hard-to-debug race conditions in a zoneless world.
• Modern DOM APIs: Features like ResizeObserver, IntersectionObserver, and modern CSS Custom Properties are now assumed to be present.
• ES Modules & Build Tooling: Our build pipeline (esbuild/Vite) is optimized for modern ES output. Down-leveling code to ES5 (required for Chrome 67) significantly increases bundle size and parsing time for the 99% of users on modern browsers.

3. Response to "Extended Polyfill Mode" Proposal

We understand your constraints, but we are unlikely to introduce an official "Extended Polyfill Mode" into the Angular CLI core.

Reasoning:

• Bundle Size Impact: Automatically integrating core-js deep polyfills encourages shipping bloated bundles to all users to support a shrinking minority.
• Maintenance: Maintaining a configuration matrix that supports EOL browsers slows down our ability to ship modern features (like Signals and Deferrable Views).

We are moving forward with Baseline to ensure the framework remains performant and secure. While we will not add native legacy modes.

[kakao-fleek-moon]

Thank you for your detailed answer.