Are browser support policies dead?

With the apparent news that Microsoft is giving up on EdgeHTML and moving to a Chromium-based rendering engine, it’s tempting to think that we no longer need to maintain browser support or testing policies.

After all, if there are only a couple of variants of rendering engine to support, do we really need to have an explicit policy?

Publicly available browser support policies are much less visible than about ten years ago. Much of this is likely due to consolidation of support for web standards, making it easier to create sites that work cross-browser without the need for explicit treatment.

But that doesn’t mean it’s a given that we ‘support’ a browser. A browser support policy isn’t for the development team (although we are one of the stakeholders) - it’s for end users, customers, customer support, sales, partners, the list goes on.

So even if you have a very simple policy in practice - for example, a kiosk app that runs only on a specific version of Chrome - it’s important to be explicit and transparent about what that support is and what it means to support it.

One of the more interesting developments is browser support automation. Microsoft are supposedly continuing development of their Chakra JavaScript engine. JavaScript itself is changing, and support for various features across engines is not consistent.

Up to now, to take advantage of the features of ES2015 and beyond, we’ve been transpiling to ES5 for all browsers alike. Now, Babel, Webpack and similar tools are starting to provide better support for delivering conditional bundles, so that older browsers will continue to receive ES5 bundles and new browsers can take advantage of native feature support. Many teams have already been doing much the same when ‘polyfilling’ web platform features.

So although the landscape has arguably become less varied for rendering engines in recent years, the same is not true for JavaScript engines, support for web platform APIs, variety in device capabilities and form factors.

If anything, browser support documents now need to encompass more: devices, browsers, features, offline expectations, you name it. This goes way beyond ‘browser support’, but still serves the same purpose: setting expectations for how your product operates, and where you will spend time on bug fixes and improvements.

Do you have an explicit browser support policy? Does it need an update or rewrite? Sounds like a fun winter holiday exercise, right?…

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.