![\"An](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/update.png?resize=620%2C279&ssl=1\")
<\/figure>\n\n\n\nClicking this button would start the process to update Chrome to the latest stable version.<\/p>\n\n\n\n
I\u2019ve asked some probing questions about how frequently they reboot, which would also force Chrome to update upon relaunch. That\u2019s the point of an \u201cevergreen\u201d browser, right? It\u2019s easy to make sure you\u2019re always using the latest and greatest version.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/a> is conditionally forced to have a faster browser upgrade path.<\/p>\n\n\n Before the advent of evergreen browsers, you would need to go to the manufacturer\u2019s website and manually download and install the update. Prior to that you had to use a CD or floppy disk.<\/p>\n\n\n\n By contrast, an evergreen browser<\/dfn> 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\u2019s manufacturer. The update itself occurs with:<\/p>\n\n\n\n Nearly all major browsers are evergreen. This includes Google Chrome, Microsoft Edge, and Mozilla Firefox.<\/p>\n\n\n\n Apple Safari is quasi-evergreen<\/a>. By this I mean it automatically receives updates, but awkwardly requires them to be done via the macOS operating system update interface, where other system-wide updates are located.<\/p>\n\n\n\n If you haven\u2019t been paying attention, the Safari team has been making a ton of improvements<\/a> to their browser in the past few months\u2014I\u2019d love to see them continue with this trend by making the browser update path decoupled from existing macOS and iOS upgrade workflows.<\/p>\n\n\n With the actual, final, no-seriously-we-mean-it-this-time death of Internet Explorer<\/a>, 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.<\/p>\n\n\n\n Spending less<\/em> time does not mean spending no<\/em> time, however.<\/p>\n\n\n Support from all evergreen browsers on caniuse.com<\/a> does not necessarily mean support exists on the device a person is using\u2014updates that have been pushed out don\u2019t automatically get instantly applied.<\/p>\n\n\n\n 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\u2019m not exempt from this urge\u2014CSS is about to go from great to amazing<\/a>, and the urge to use new features is very real.<\/p>\n\n\n\n Instead, wait a bit. Work with the platform\u2019s ability to create progressively enhanced experiences<\/a> with CSS and JavaScript.<\/p>\n\n\n The web is really good at being resilient<\/a>, provided you work with its grain<\/a>.<\/p>\n\n\n\n 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\u2019t.<\/p>\n\n\n\n Instead of looking at the support table for something on caniuse.com and thinking, \u201cI wish more browsers supported this feature so that I could use it!\u201d, you can instead think \u201cI\u2019m going to use this feature today, but treat it as an experimental feature.\u201d<\/p>\u2014Jeremy Keith, \u201cContinuous partial browser support\u201d<\/a><\/cite><\/blockquote>\n\n\n You can use JavaScript to query whether or not a browser supports a certain feature. For example, the In this example, I am inverting a request for support for a browser\u2019s Assume geolocation functionality isn\u2019t supported to start and provide a way to accommodate the person using this browser (say manually typing in a ZIP Code, etc.). With this use case covered, you can then confidently build an experience for browser that support geolocation.<\/p>\n\n\n\n This thinking also extends to all other browser features and capabilities.<\/p>\n\n\n Like most other programming languages, CSS also lets us use For example, the For this example, this progressive enhancement approach ensures that a component\u2019s content and functionality is preserved for every browser, but only creates fancy layouts for browsers capable of supporting them.<\/p>\n\n\n Yes, this approach adds more code, and more code means more complexity and maintenance. But it\u2019s very important code. You might even call it technical debt and you\u2019d be correct. But technical debt can be a good thing, like an investment in the future<\/a>.<\/p>\n\n\n\n You may want to remove that complexity when it\u2019s 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:<\/p>\n\n\n In terms of waiting, I\u2019d 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:<\/p>\n\n\n\n I would also say that rough six month timeframe is in terms of a general, global web audience<\/a>. 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<\/a>.<\/p>\n\n\n Remember: survivor bias<\/a> is real. Is the brand new feature you\u2019re using preventing someone from using your website or web app? I say this because some people:<\/p>\n\n\n\n There isn\u2019t a single, specific device, browser, and person we cater to when creating a web experience.<\/strong> 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.<\/p>\n\n\n\n Consider doing the hard work to make it easy and never remove feature queries and We\u2019re 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.<\/p>\n\n\n\n Who knows what devices browsers will be included with in the future, or what capabilities they\u2019ll have? Future-proof (and, er, past-proof) yourself with an approach that accommodates it.<\/p>\n\n\n\nEvergreen browsers<\/h3>\n\n\n
![\"A](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/s_D0AD31FBF658C09667EF06883B4D142FA961BADADF5839F7F681E757E12AFFB1_1641571594625_Floppy_Disk_of_Netscape_Navigator-scaled.jpg?resize=2560%2C1707&ssl=1\")
The browsers themselves<\/h4>\n\n\n
![\"A](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/01\/s_D0AD31FBF658C09667EF06883B4D142FA961BADADF5839F7F681E757E12AFFB1_1641825666666_safari-update.png?resize=1560%2C1030&ssl=1\")
<\/figure>\n\n\n\nThe situation<\/h4>\n\n\n
Delayed effects<\/h3>\n\n\n
Leverage the platform<\/h3>\n\n\n
JavaScript<\/h4>\n\n\n
Navigator<\/code> interface<\/a> provides a mechanism for querying a user agent\u2019s capabilities.<\/p>\n\n\n\nif (!(\u201cgeolocation\u201d in navigator)) {\n \/\/ Logic if a user's current geographic location isn't available\n} else {\n \/\/ Logic that is based on a user's current geographic location\n}<\/code><\/pre>\n\n\n\nGeolocation<\/code> interface. Although its syntax is initially a little confusing to parse, it helps emphasize a progressive enhancement approach.<\/p>\n\n\n\nCSS<\/h4>\n\n\n
if<\/code>-like statements.<\/p>\n\n\n\n@supports<\/code> at rule<\/a> 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\u2019t will ignore them. It is a concise, clever, adaptable solution.<\/p>\n\n\n\n.component {\n \/* Base appearance *\/\n}\n\n@supports (grid-template-columns: subgrid;) {\n .component {\n \/* Styling and positioning enhancement tweaks if subgrid is supported *\/\n }\n}<\/code><\/pre>\n\n\n\nWhen can I remove this stuff?<\/h3>\n\n\n
Patience is a virtue<\/h4>\n\n\n
Maybe don\u2019t<\/h4>\n\n\n
@supports<\/code> statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.<\/p>\n\n\nThe future is uncertain<\/h3>\n\n\n
\n\n\n\n