In HTML, how does <script type="module" src="app.js"></script> behave with respect to the parser compared with a classic <script src="app.js"></script>, and what effect do the defer and async attributes have on a module script?

## The default flips The single most important fact is that `type="module"` changes the default from blocking to deferred: ```html <script src="app.js"></script> <!-- blocks the parser --> <script type="module" src="app.js"></script> <!-- deferred, never blocks --> ``` A module script is fetched in parallel with parsing and evaluated after the document has been parsed, before `DOMContentLoaded`. So a module in `<head>` is already doing the right thing, and its DOM queries will find the elements they are looking for. This holds for **inline** module scripts too. `<script type="module">init()</script>` in `<head>` does not run immediately the way an inline classic script does — it waits for parsing to finish. That asymmetry surprises people who have internalised "inline means synchronous". ## What the graph adds A module is not one file. Before evaluation the browser must fetch the entire dependency graph reachable from the entry file, then evaluate it bottom-up. Everything a module imports is therefore on the critical path for that module's execution: a chain of four imports is four sequential round trips unless the server pushes or the URLs are otherwise warmed. If two tags reference the same module URL, the browser fetches and evaluates it once and shares the result. ## defer on a module script `defer` has **no effect** on a module script. It is already deferred, and the attribute is simply ignored. Seeing `<script type="module" defer src="...">` in a codebase is harmless noise, not a second layer of postponement. ## async on a module script `async` does apply, and it means the same thing it means for a classic script: evaluate at the first opportunity after the fetch completes — here, after the whole graph is available — with no ordering guarantee relative to other scripts, and possibly before or after `DOMContentLoaded`. The one place it differs from classic behaviour is inline scripts: `async` is ignored on an inline classic script but honoured on an inline module script. ```html <script type="module" async> import { ping } from './telemetry.js'; ping(); </script> ``` That runs as soon as `telemetry.js` has been fetched, whether or not parsing has finished. ## The CORS difference Module scripts are always fetched in CORS mode. A classic `<script src="https://cdn.example.com/lib.js">` works with no special headers (which is why cross-origin classic script errors are opaque and reported as "Script error"). The same URL loaded as a module fails unless the server sends `Access-Control-Allow-Origin`. This is a real, frequent deployment bug when a team switches a CDN-hosted file from a classic tag to a module tag, and it is worth naming in an interview because it shows you have actually shipped modules. Relatedly, module fetches use the credentials rules of CORS, and the `crossorigin` attribute controls whether credentials are sent, exactly as it does for other CORS-mode subresources. ## nomodule and the legacy fallback `nomodule` is an attribute you put on a **classic** script. A browser that understands module scripts ignores any script carrying it; a browser that does not understand modules also does not understand `nomodule`, so it runs the script normally. That produces the module/nomodule pattern: ```html <script type="module" src="modern.js"></script> <script nomodule src="legacy.js" defer></script> ``` Modern browsers run `modern.js` only; a browser with no module support runs `legacy.js` only. This pattern mattered around 2017–2019 for shipping untranspiled code to browsers that could handle it. Every browser still receiving security updates supports modules, so today it is mostly a historical technique — worth recognising in old markup and knowing why it works, not worth adding to a new project. ## Putting it together If someone asks "what is the difference between defer and type=module", the honest answer is: for a single external file, the parser behaviour is nearly identical, because modules are deferred. The differences are the module *system* (a dependency graph fetched before evaluation, one evaluation per URL), the CORS-mode fetch, and the fact that `async` reaches inline scripts. Those are the details that separate a memorised answer from a used-it answer.