What does this change?

DCR's build process has historically built and served two web builds - 'legacy' and 'modern' with a 'mustard cut' ^{1 2} to determine the split between the two.

This change removes the legacy build with the assertion that it is not relevant anymore.

The current mustard cut is based on whether the browser supports ES6 module script tags

Loading the legacy build

We add script tags to the HTML page that should only load the legacy scripts if the browser does not support ES6 modules via the nomodule attribute:

Setting window.guardian.mustardCut

We also set window.guardian.mustardCut based on nomodule:

But afaics this is not used for anything except to load a dynamic import polyfill for browsers that pass the mustard cut (i.e. support es modules):

However the repo states that this library shouldn't be used anymore as all browsers that support esmodules support dynamic imports:

https://github.com/GoogleChromeLabs/dynamic-import-polyfill

Why?

1. It is the year 2025 and browser support has improved greatly since the mustard cut was introduced
2. Allows us to simplify and remove an exotic part of our build process
3. Reduces developer confusion
4. Allows us to concentrate on only one build for web
5. Allows to to remove the legacy Babel dependency which removes 200MB of dependencies Remove Babel #13782
6. Eases the upgrade path to modern build tools such as Vite

Supporting Evidence

1. Usage of the legacy build is 0.001% of the regular build

Querying the sampled Athena logs for assets.guim.co.uk on 2025-04-22 we can extrapolate the requests for each type of build to:

Hence requests for legacy scripts account for 0.001% of all scripts requests.

Given we fire ~33 requests for scripts per page, these figures do not exactly correlate to users or page views, which will be substantially lower.

TODO - check if legacy requests are bots

2. All browsers with >= 0.1% usage support ES6 modules

The old method of calculating browser usage from GA and subsequent transpilation support has been deprecated. Using @ashishpuliyel 's spreadsheet to query Ophan usage from the datalake and referencing https://caniuse.com/es6-module, we can see for the vast majority of browsers (with two exceptions) support ES6 modules.

The two exceptions are:

I think the usage amounts are low enough to discount.

3. Core Experience

Given we server side render our content we still deliver the 'core' experience of our journalism that is not dependant on client side JS.

We could instead choose to deliver a close to zero-JS experience for browsers that do not cut the mustard rather than serving a legacy build which increasingly degrades over time.

aiui this is closer to the 'mustard cut' described by ¹² where the browsers that do not cut the mustard get a close to zero JS experience rather than a semi-broken experience.

4. Targeted fixes for older browsers

We have recently taken the approach of targeted fixes for older browsers when we spot errors or get user complaints. This then becomes part of the main build available to all users.