What does the nomodule attribute on an HTML <script> tag do, and how does pairing it with <script type="module"> let one page serve two different bundles?

## The two behaviours that make the pattern work ```html <script type="module" src="/bundle.modern.js"></script> <script nomodule defer src="/bundle.legacy.js"></script> ``` Nothing in this markup detects anything. It relies on two separate rules meeting in the middle: 1. A browser that implements ES modules must honour `nomodule` — it sees the attribute on a classic script and does not execute it. 2. A browser that does not implement modules does not recognise `type="module"` as a supported script type. An unknown `type` means the element is treated as a data block and not executed. It also does not know what `nomodule` means, and unknown attributes are simply ignored, so it runs the classic script normally. The result is a mutually exclusive pair with no runtime cost and no flash of wrong behaviour: exactly one bundle executes per browser. ## What it was for When module support landed across browsers, teams were transpiling everything to ES5 and shipping polyfills to every visitor, including the large majority whose browsers needed none of it. The module/`nomodule` pair let one HTML document serve a lean modern build to capable engines and the old heavyweight build to the rest. Because module scripts defer by default, `defer` was typically written on the `nomodule` tag so the two halves had matching timing. ## Why it has faded Module support has been universal in evergreen browsers since 2018, so the legacy bundle is downloaded by almost nobody while still needing to be built, tested and deployed. Meanwhile the transition era left real bugs: Safari 10.1 supported modules but did not honour `nomodule`, so it fetched and ran the legacy bundle as well — the reason the well-known inline "nomodule fix" snippet existed. Edge 16–18 had related issues. Those quirks mean the pattern was never quite the free lunch it looked like. Seeing it in a template today is usually a sign of an old build configuration rather than a live requirement. Removing it means deleting the legacy tag and the build target that produces it — and, if you support a specific old browser deliberately, being explicit about which one instead of relying on an accidental double-negative. ## Facts to keep straight - `nomodule` is boolean: its presence is the whole signal, and `nomodule="false"` still means "skip me", because the value is never read. - It is meaningful only on classic scripts. Putting it on a `type="module"` tag makes no sense — that tag runs precisely in the browsers that would skip it. - It is a capability signal about module support, not about any other modern syntax. A browser can support modules and still lack a specific newer language feature, so `nomodule` is a coarse proxy, not a guarantee that your modern bundle parses. ## Answering well Explain the two complementary ignore rules — not "the browser checks whether it supports modules", which misses that no check happens — then state plainly that the pattern is historical, and that the honest recommendation for a new page is one module bundle and no fallback.