“Evergreen” Does Not Mean Instantly Current
An “evergreen” browser is one that updates itself automatically. The browser pulls down new code from its manufacturer once it’s released, and the update applies with a prompt to restart, a background download applied on restart, or on device restart. Nearly all major browsers—Chrome, Edge, Firefox—work this way.
That doesn’t mean every user is running the latest version at all times. A coworker of mine is a capable, full-time web developer who still has an outdated Chrome because rebooting would disrupt their workflow. Their laptop is powerful enough to go months without a restart, so the browser update waits. Ironically, a slower machine would get the upgrade path sooner, since it would reboot more often.
Quasi-Evergreen Safari
Apple Safari is only quasi-evergreen. It does receive updates automatically, but those updates come through the macOS (or iOS) system update interface, alongside OS-level changes. The Safari team has shipped a stream of improvements recently, but the browser’s fate is still tied to the operating system’s upgrade cycle.
The Delayed Effects of an “Evergreen” Web
With Internet Explorer finally retired, evergreen browsers dominate the desktop and laptop landscape. That’s less time spent worrying about browser support. But “less” isn’t “none.”
A feature listed as supported in all evergreen browsers on caniuse.com may not exist on a user’s actual device. Pushed updates aren’t instantly applied. Users procrastinate, corporate policies delay deployments, and hardware refresh cycles lag behind.
The better approach is patience: wait before adopting the newest shiny feature, and use progressive enhancement to serve experiences that adapt to what each browser actually supports.
Building with Feature Detection
The web platform is resilient when you work with its grain. CSS and JavaScript can conditionally deliver experiences: use the new feature when available, provide an alternative when not.
In JavaScript, the Navigator interface queries a user agent’s capabilities. Inverting a request—say, checking that geolocation is not supported—helps reinforce a progressive enhancement approach. Assume the feature is missing, provide a fallback (like manual ZIP code entry), then build the enhanced experience on top.
CSS has its own conditional, the @supports at rule. It checks whether a browser supports something and applies styles accordingly. Browsers that honor the feature use those styles; browsers that don’t ignore them. Content and core functionality are preserved everywhere; fancy layouts appear only where possible.
When to Remove Feature Detection
This approach adds code, and more code means more complexity. That’s technical debt—but it can be prudent debt, an investment in future flexibility.
When to clear it? A conservative estimate is roughly six months from a feature’s release before even investigating removal. That accounts for reboots, update procrastinators, users stuck on old hardware, corporate update policies, and the reality of a general global web audience. That timeline shifts if you cater to a specialized group—know your users through analytics and conversation.
The Case for Keeping It
Survivor bias is a real concern. Some users are forced onto third-party-managed devices. Some avoid updates intentionally, fearing they’ll lose access to tools they rely on. Some know their device is the problem but lack the knowledge to fix it. And some run “dead” evergreen browsers—devices that used to receive updates but are no longer supported by their manufacturers.
There is no single device, browser, or person to target. Web experiences must adapt to a near-infinite combination of circumstances. Feature queries and @supports rules are the mechanism for that adaptation. Keeping them in place means your site gracefully handles both the past and the future.
Beyond the Desktop
Browsers appear everywhere now—phones, watches, TVs, kiosks, game consoles, cars, even vending machines and refrigerators. No one can predict the next device with a browser engine. Building with conditional, progressively enhanced code is the most sensible way to remain useful across that uncertain landscape.
