I have a coworker who is smart, capable, and technologically-literate. Like me, they work on the web full-time.
When they are sharing their screen in a meeting, I find myself disassociating fixating on the red update button in their copy of Chrome.
Clicking this button would start the process to update Chrome to the latest stable version.
I’ve asked some probing questions about how frequently they reboot, which would also force Chrome to update upon relaunch. That’s the point of an “evergreen” browser, right? It’s easy to make sure you’re always using the latest and greatest version.
It turns out they prefer to wait until they absolutely have to because of the disruption it would cause in their daily workflow. Their behavior makes sense. They are prioritizing the quality of their overall computing experience, rather than catering to the demands of one specific app.
Like me, my coworker also uses a top-of-the-line laptop to get things done. This means that the laptop can go for months without needing a reboot. Ironically, this might be a situation where a craptop is conditionally forced to have a faster browser upgrade path.
Evergreen browsers
Table of Contents
Before the advent of evergreen browsers, you would need to go to the manufacturer’s website and manually download and install the update. Prior to that you had to use a CD or floppy disk.
By contrast, an evergreen browser is any browser that can automatically update itself. By this, I mean the browser will automatically pull down the code required to add new features and fix bugs once it has been released by the browser’s manufacturer. The update itself occurs with:
- a prompt shown to the person using the browser that prompts an application restart,
- a download that happens in the background and gets applied on application restart, or
- on device restart.
The browsers themselves
Nearly all major browsers are evergreen. This includes Google Chrome, Microsoft Edge, and Mozilla Firefox.
Apple Safari is quasi-evergreen. By this I mean it automatically receives updates, but awkwardly requires them to be done when updating the macOS operating system with other system-wide updates.
If you haven’t been paying attention, the Safari team has been making a ton of improvements to their browser in the past few months—I’d love to see them continue with this trend by making the browser update path decoupled from existing macOS and iOS upgrade workflows.
The situation
With the actual, final, no-seriously-we-mean-it-this-time death of Internet Explorer, evergreen browsers are now the main consideration for desktop and laptop browsers. This is great! It means we can spend a lot less time fretting about who can use what.
Spending less time does not mean spending no time, however.
Delayed effects
Support from all evergreen browsers on caniuse.com does not necessarily mean support exists on the device a person is using—updates that have been “pushed” out don’t automatically get instantly applied.
Because of these two factors, I advocate for tempering your excitement with some restraint. It can be very tempting to rush and use the new and the shiny. Believe me, I’m not exempt from this urge—CSS is about to go from great to amazing, and the urge to use new features is very real.
Instead, wait a bit. Work with the platform’s ability to create progressively enhanced experiences with CSS and JavaScript.
Leverage the platform
The web is really good at being resilient, provided you work with its grain.
Both CSS and JavaScript have the ability to conditionally serve up experiences for browsers that support new features while providing alternatives for those that don’t.
Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”
—Jeremy Keith, “Continuous partial browser support”
JavaScript
You can use JavaScript to query whether or not a browser supports a certain feature. For example, the Navigator interface provides a mechanism for querying a user agent’s capabilities.
if (!(“geolocation” in navigator)) { // Logic if a user's current geographic location isn't available
} else { // Logic that is based on a user's current geographic location
}In this example, I am inverting a request for support for a browser’s Geolocation interface. Although its syntax is initially a little confusing to parse, it helps emphasize a progressive enhancement approach. That is, assume geolocation functionality isn’t supported and be sure to prove a way to accommodate the person using this browser. This could have been any other feature, like letting a user type in an address or ZIP Code. With that use case covered, you can then confidently build an experience that utilizes a browser’s geolocation capabilities.
This thinking also extends to all other browser features and capabilities.
CSS
Like most other programming languages, CSS also lets us use if-like statements.
For example, the @supports at rule allows you to create a conditional statement that targets whether or not a browser supports something, and then apply logic to it. Browsers that honor the feature will utilize those styles, and browsers that don’t will ignore them. It is a concise, clever, adaptable solution.
.component { /* Base appearance */
} @supports (grid-template-columns: subgrid;) { .component { /* Styling and positioning enhancement tweaks if subgrid is supported */ }
}For this example, this progressive enhancement approach ensures that a component’s content and functionality is preserved for every browser, but only creates fancy layouts for browsers capable of supporting them.
When can I remove this stuff?
Yes, this approach adds more code, and more code means more complexity and maintenance. But it’s very important code. You may even call it technical debt and you’d be correct. But technical debt can be a good thing, like an investment in the future.
You may want to remove that complexity when it’s no longer needed. Knowing the right time to do that in this age of evergreen browsers is difficult, but I have a couple of suggestions:
Patience is a virtue
In terms of waiting, I’d advise a conservative 6-ish months from release of a new feature before even beginning to think about investigating if you can remove feature detection. This accounts for:
- Reboots
- Update procrastinators
- Update avoiders
- Hardware refresh cycles
- Corporate update policies,
- etc.
I would also say that rough six month timeframe is in terms of a general, global web audience. This guesstimate changes if you cater to a specialized audience. The way to know who you actually serve? Analytics, yes, but also talking to people.
Maybe don’t
Remember: survivor bias is real. Is the brand new feature you’re using preventing someone from using your website or web app? I say this because some people:
There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.
Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.
The future is uncertain
We’re long past the age of desktop computers. Browsers are showing up in more and more places: phones, tablets, watches, ebook readers, digital cameras, kiosks, televisions, home assistants, vending machines, photo frames, graphing calculators, ATMs, point of sale terminals, exercise equipment, video game consoles, billboards, refrigerators, virtual reality, and cars.
Who knows what devices browsers will be included with in the future, or what capabilities they’ll have? Future-proof (and, er, past-proof) yourself with an approach that accommodates it.
Thank you to to Jim Nielsen for their feedback.
