The future of Firefox

• October 30 2024
• 5 min. read

A while back I came across Firefox on the brink?. In the article, the author wonders if we're seeing the final decline of Firefox.

According to the article, the US Web Design System provides a set of standards and guidelines for US Federal Government websites. Part of these guidelines include browser support:

The current major version of the design system (3.0.0) follows the 2% rule: we officially support any browser above 2% usage as observed by analytics.usa.gov.

Source: Browser Support

When the article was written (10/15/2024) Firefox usage was 1.9% in the last 30-day period.

What happens if the support falls under 2% for government websites and the digital service drops support for Firefox?

According to Firefox on the brink:

• Once Firefox slips below the 2% threshold in the [US] government’s visitor analytics, USWDS tells government web devs they don’t have to support Firefox anymore.
• When that word gets out, it spreads quickly to not only the front-end dev community but also the corporate IT departments for whom some web devs work. Many corporations do a lot of business with the government and, thus, whatever the government does from an IT standpoint is going to influence what corporations do.
• Corporations see this change as an opportunity to lower dev costs and delivery times, in that it provides an excuse to remove some testing (and, in rare cases, specific coding) from their development workflow.

… and just like that, in less time than you might think, Firefox — the free/open-source browser that was supposed to save the world from the jackboots of Internet Explorer (which had killed Firefox’s ancestor, Netscape Navigator) — is reduced to permanent status as a shrinking part of the fractured miscellany that litters the bottom of browser market-share charts.

There are also other potential consequences. With only two rendering engines left in the market (Blink for Chromium browsers and WebKit for Safari) the pace of innovation will slow down, potentially to a crawl.

The Chromium project has a written procedure to develop new features. WebKit has decided not to implement them because of perceived privacy concerns.

If they are the only two major rendering engines (Blink and WebKit) in the market there is no real way to stimulate either browser to change their stance on development or to force them to work together so we'll have a unified platform to develop apps.

There is a related area that concerns me.

Other tools use browser market share to make determinations about the tasks they are performing.

Browserslist provides a list of targeted browsers matching preset criteria. It is the list that tools like Autoprefixer, Babel, ESLint, and PostCSS use to determine when to use a polyfill or provide compatibility layers.

Would Browserslist include Firefox in its list of supported browsers?

Browserslist default query covers the following browsers:

• Those with at least 0.5% support
• The last 2 versions of each browser
• Firefox ESR
• Browsers that are not dead (meaning that they've had official support and security updates within the last 24 months)

While it aims for the widest possible support globally, in my opinion, it is too permissive and it will add unnecessary bloat to web applications.

Let's change the defaults to those browsers with more than 2% support, just like the UWDS does for their projects.

If I run the query >= 2% in the browserslist playground to only query for browsers with more than 2% of support, we get some interesting numbers:

If we narrow the results to only North America (>= 2% in US), we get a narrower set of results.

So what happens if your browser (firefox in this case) doesn't appear in the Browserslist list that you selected?

Most of the tools using Browserslist use it to decide if they should use older techniques or polyfills for specific browsers.

For example, Babel and PostCSS preset/env plugins will use the browserslist values to decide if any plugins or core-js features need to be included in the transpiled project.

So, if a browser doesn't appear in the results of a browserslist queries, it will not use modern features supported by the browser creating larger code bundles or unnecessary prefixes added to your stylesheets.

Rather than use the default, you can query based on the features that you need for your site.

You can use feature queries (@supports) in CSS to only run code if the feature is (or isn't) available.

For example, this code will only execute when the browser does not support subgrid.

@supports not (grid-template-columns: subgrid) {
  /* rules in here */
}

In Javascript we have two ways to do feature detection. The first one is to check if the feature is available in its parent object.

if ("geolocation" in navigator) {
  // Access navigator.geolocation APIs
}

The second one is to programmatically create an object and add the property we're testing and see if it persists.

function supports_canvas() {
  return !!document.createElement("canvas").getContext;
}

Any of these techniques would help reduce the size of your codebase since we're only using native features when they are supported and choose what, if any, fallback to use when it's not.

• Browsers,
• Firefox

Edit on Github