'Evergreen” Does Not Mean Immediately Available

A colleague, a skilled and tech-savvy web developer like myself, consistently displays a nagging Chrome update notification. This seemingly minor detail highlights a larger issue: the reality of "evergreen" browsers. While the automatic update feature is beneficial, it doesn't guarantee immediate adoption by all users.

My colleague prioritizes uninterrupted workflow over immediate browser updates, a perfectly reasonable approach. High-end laptops, capable of months of use without a reboot, ironically exacerbate this delay, unlike less powerful machines that might necessitate more frequent restarts and thus faster update cycles.

Evergreen Browsers: The Reality

Before evergreen browsers, manual updates were the norm, a process involving website downloads or even physical media. Evergreen browsers automate this, updating via prompts requiring restarts, background downloads activated on restart, or system restarts.

Major browsers (Chrome, Edge, Firefox) are largely evergreen. Safari, however, presents a unique case, relying on macOS updates for browser updates – a less elegant solution. Ideally, Safari's update mechanism would be decoupled from the OS update process.

Internet Explorer's demise solidifies evergreen browsers as the standard, simplifying compatibility concerns. However, this doesn't eliminate the need for careful consideration.

Delayed Updates: The Catch

caniuse.com data doesn't reflect real-world browser versions. Updates aren't instantly applied across all devices. This necessitates a cautious approach to new features.

Resist the temptation to immediately embrace the latest features. Instead, prioritize progressively enhanced experiences using CSS and JavaScript.

Leveraging the Platform

The web's resilience lies in adapting to its diverse landscape. CSS and JavaScript offer mechanisms to conditionally serve content based on browser capabilities.

Instead of lamenting feature support, embrace a mindset of experimental implementation.

JavaScript Feature Detection

JavaScript's Navigator interface allows for feature detection. For example:

if (!(“geolocation” in navigator)) {
  // Handle lack of geolocation support
} else {
  // Utilize geolocation functionality
}

This approach prioritizes fallback mechanisms before implementing new features.

CSS Conditional Styling

CSS's @supports rule provides conditional styling:

.component {
  /* Base styles */
}

@supports (grid-template-columns: subgrid;) {
  .component {
    /* Enhanced styles for subgrid support */
  }
}

This ensures basic functionality across all browsers while enhancing the experience for capable ones.

Removing Feature Detection: When and How?

While adding feature detection increases code complexity, it's a worthwhile investment. Consider removing it only after a significant period (around six months post-feature release) to account for various update delays. This timeframe is a general guideline; specialized audiences may require adjustments. Analytics and user feedback are crucial in determining the optimal removal time.

However, completely removing feature detection might not always be advisable. Consider the users who:

• Rely on managed devices.
• Deliberately avoid updates.
• Lack the technical skills to update.
• Use unsupported browsers.

The web's success stems from its adaptability to a vast array of devices and users. A robust approach prioritizes compatibility and graceful degradation.

Future-Proofing Your Web Experiences

The proliferation of devices necessitates a future-proof strategy. Consider the expanding range of devices (phones, tablets, smart TVs, etc.) and their varying capabilities. Prioritizing compatibility across this spectrum ensures a consistent user experience.

Thanks to Jim Nielsen for their feedback.

The above is the detailed content of 'Evergreen” Does Not Mean Immediately Available. For more information, please follow other related articles on the PHP Chinese website!