Spike ways of cutting the mustard (e.g. guarding everything with a feature check)

[stevenjmesser]

What

Spike alternative ways to cut the mustard. For example, returning early if the browser does not support a feature like Promise.prototype.finally() in order to provide a “cut” where only the browsers that support Promise.prototype.finally execute the rest of the JavaScript. Promise.prototype.finally() is only picked as an example – we should explore other features that Browserslist supports.

We might also need to think about:

• how this interacts with the inline script that adds the js-enabled class to the body
• if we can avoid downloading JavaScript that will never be run

Checklist

• Have a look at other libraries to see what they can do
• Pool together some ideas of things we can try, and some loose evaluation criteria. Then start the spikes!

Why

One way of doing this is to load our JavaScript using the type="module" attribute in the script tag. 'Modern' browsers understand what this means whilst older browsers like IE11 ignore it. However, with this approach 'modern' browsers includes browsers going back to 2017 (Chrome 61, Edge 16, Safari 10.1, Opera 48) and includes versions of browsers which according to our analytics data are not really used.

Assuming we want to try and provide a 'clean' cut – i.e. only run JS if it's going to run successfully – we may end up providing polyfills, or avoiding features, in order to support browsers that nobody are really using.

Spiking alternative approaches may give us a better solution with a more sensible way to make this cut.

Assumptions

• We want to give service teams a recommended approach for including the JavaScript for our components (as opposed to providing modern JS with no transpilation or polyfills and leaving it up to service teams to implement the rest as part of their build pipeline)
• We want a 'clean cut' (as opposed to letting JS 'blow up' in older browsers)

Timebox

We timeboxed this to 21 Feb.

Who is working on this?

Spike lead: Romaric

Spike buddy: Brett & Colin

Questions to answer

• Will some JavaScript features "blow up" before our cut-the-mustard checks get to run?
  Thinking in terms of arrow functions, try… (optional) catch, Promise: finally, Error: cause
• With defer as default for <script type="module">, could 3rd party scripts run first?
  Service teams will need to take care that tracking and analytics doesn't delay component load
• What about legal obligations showing cookie banners?
  For our Cookie banner (client-side only) can we hide it behind a cut-the-mustard check?
• How do we deal with global scope?
  JavaScript modules use this globalThis, will that cause window.GOVUKFrontend problems?
• Is the approach compatible with service teams existing build tools?
• How can browserlist help?

Done when

You may find it helpful to refer to our expected outcomes of spikes.

• Questions have been answered or we have a clearer idea of how to get to our goal
• Findings have been reviewed and agreed with at least one other person
• Findings have been shared internally, e.g: via a write-up on the ticket, at a show & tell or team meeting, including our best bet (the thing we think will work best)

[stevenjmesser]

Thoughts from @colinrotherham:

• Will some JavaScript features "blow up" before our cut-the-mustard checks get to run?
  Thinking in terms of arrow functions, try… (optional) catch, Promise: finally, Error: cause

• With defer as default for <script type="module">, could 3rd party scripts run first?
  Service teams will need to take care that tracking and analytics doesn't delay component load

• What about legal obligations showing cookie banners?
  For our Cookie banner (client-side only) can we hide it behind a cut-the-mustard check?

• How do we deal with global scope?
  JavaScript modules use this globalThis, will that cause window.GOVUKFrontend problems?

[romaricpascal]

If we focus the mustart-cutting side to the scenario where service teams load the whole bundled file from the release Zip (and follow our Getting Started), we should also consider what's the impact for services that have their own bundlers/assets-pipelines and if our solution can work for them (capabilities of their tools to set it up and/or overhead on their build).

[domoscargin]

It'd probably be beneficial to complete #3292 asap so we have a sense of where our current features might cut us off anyway.

Also, @colinrotherham offered up using browserslist as a potential topic for knowledge-sharing, so maybe that'd be a good thing to prioritise as well so everybody has the same browserslist foo.

[colinrotherham]

Thanks @stevenjmesser, I've improved my previously-scruffy notes above!

[romaricpascal]

Write up available (though not publicly) at: https://docs.google.com/document/d/180C-e5giOKQBZbh78skcNzE2o1DialI-0kBEgH_kP48/edit?pli=1#
Notes from playback (not publicly available either): https://docs.google.com/document/d/1jhmS8D-V2fiMYV3qRDtES__WUXeHy87aDhkWPukMxMA/edit#

Next step: #3369