This example comes directly from the WHATWG HTML specification:
<!DOCTYPE html>
<html lang="en">
<title>IRCFog</title>
<link rel="modulepreload" href="app.mjs">
<link rel="modulepreload" href="helpers.mjs">
<link rel="modulepreload" href="irc.mjs">
<link rel="modulepreload" href="fog-machine.mjs">
<script type="module" src="app.mjs"><link rel="modulepreload"> tells the browser to fetch and initialize a module ahead of time (MDN). Unlike <link rel="preload">, which only downloads resources into the HTTP cache, scripts preloaded with <link rel="modulepreload"> are parsed and compiled early by the browser’s module loader so they are ready when referenced by <script type="module">. In practice this is almost always used for JavaScript modules: if the as attribute is omitted, the destination defaults to "script", and support for other module types remains spotty. Without these hints, the browser has to download app.mjs, parse it to find its import specifiers, fetch those dependencies, parse those to find their imports, recursively discovering each graph level one HTTP request at a time. On a mobile connection with 100ms round-trip latency and a dependency tree four levels deep, that’s ~400ms of dead time before execution begins. HTTP/2 multiplexing, cache hits, and speculative parsing reduce it, but none of them eliminate the fundamental problem: the browser cannot see the graph until it fetches and parses each file.
The problem is that every path in a <link rel="modulepreload"> element is already declared in a JS import statement inside those files. The dependency graph exists in two places — HTML and JS — and the browser follows the JS imports regardless of what the modulepreload elements say. As code evolves — modules renamed, added, removed — the HTML doesn’t update itself. A stale modulepreload that points to a file that no longer exists wastes a network request. Worse, if the old file still exists at that path, the browser downloads something the application never uses — a performance penalty imposed by the very mechanism designed to improve performance. A missing modulepreload means the waterfall returns for that dependency. Neither case produces a runtime error. A 404 appears in the console or server logs if the old file is gone, but nothing connects it back to a modulepreload/import mismatch — it’s just a failed network request among hundreds. To keep the two graphs in sync, you need build tooling.
If you’ve seen this pattern in production, it was generated by Vite, SvelteKit, Nuxt, or a similar framework, because maintaining it by hand is untenable.
This is the architecture the web platform shipped. It wasn’t the only option.
In 2009, I proposed a declarative alternative that would have put the dependency graph in HTML — one source of truth, visible to the browser’s networking layer before any JS executes. The discussion ended almost immediately. After a few responses from browser engineers, the thread went quiet. There was no extended design exploration, no prototype, no attempt to refine the idea. On the WHATWG mailing list, once a thread stops receiving implementer engagement, the proposal is effectively dead.
The absence of declarative dependency loading went on to spawn an entire category of workaround software — LABjs, RequireJS, AMD, SystemJS — all solving in JavaScript what the browser refused to solve in markup. Those tools are now largely obsolete, replaced by ES modules and bundlers. But the underlying problem persists: the browser still can’t see the graph without parsing JS first, which is why your framework does the bookkeeping for you.
The Problem: Dependency Discovery Requires Fetching
ES modules moved the dependency graph into JavaScript to try to create a single module system that works across Node, browsers, and other runtimes. That’s an ambitious language-design goal, but it left the browser’s HTML parser blind to dependencies. When a browser hits <script type="module" src="app.js">, it fetches the file, parses it to discover import specifiers, fetches those, parses those — discovering the dependency graph incrementally, one module at a time, rather than reading it from the markup upfront.
modulepreload exists to fix this. But it has fundamental design problems that a better solution would have avoided.
Three-Way Duplication
In the spec example above, the dependency graph lives in three places: the import specifiers inside the JS files, the <link rel="modulepreload"> elements that hint the browser to prefetch them, and the <script type="module"> element that triggers execution — two independent declarations of the same graph, with no validation layer between them. With depends, it would be one:
<script id="helpers" src="helpers.mjs"></script>
<script id="irc" src="irc.mjs"></script>
<script id="fog" src="fog-machine.mjs"></script>
<script src="app.mjs" depends="helpers irc fog"></script>No Enforcement
Rename helpers.mjs to utils.mjs and update the JS import — the application works. The orphaned <link rel="modulepreload" href="helpers.mjs"> element stays, fetching a file that no longer exists. A 404 appears in the console, but no runtime error is thrown. Nothing connects the failed request to the stale modulepreload.
Optional Dependency Fetching
From the spec:
“A browser may additionally also choose to automatically fetch any dependencies of the module resource.”
And from the algorithm:
“Generally, performing this step will be beneficial for performance, as it allows pre-loading the modules that will invariably be requested later… However, user agents might wish to skip them in bandwidth-constrained situations, or situations where the relevant fetches are already in flight.”
The spec acknowledges these fetches will “invariably” be needed — then gives browsers blanket permission to skip them. MDN warns developers directly:
“The only approach to ensure that all browsers will try to preload a module’s dependencies is to individually specify them.”
Since recursive dependency fetching is optional, browser behavior is implementation-defined. Rich Harris — creator of Svelte and SvelteKit — built a demo that adds artificial latency to make the waterfall visible: Chrome loaded in 1 second while Firefox and Safari took 3, in part because only Chromium supported modulepreload at the time. Firefox didn’t add support until version 115 in July 2023 — five years after Chrome 66 shipped it in April 2018. For half a decade, the only way to avoid the waterfall was to target a single browser engine or use a build tool.
By contrast, depends avoids recursive graph discovery entirely. It tells the browser what to fetch next, rather than relying on behind-the-scenes implementation details. depends="a b c" declares the graph in markup — the browser checks whether elements a, b, and c have loaded, then proceeds. No recursion. No ambiguity about how deep to walk. The simplest thing that could possibly work, but not any simpler.
Scripts Only
modulepreload addresses script-to-script dependencies. It does nothing for the script-depends-on-stylesheet problem — the performance issue that started this entire conversation.
File-level modularity — one file, one cohesive unit of functionality — is not a modern invention. It goes back to C translation units, Java classes, and every language that organizes code into files that can be compiled, tested, and loaded independently. It’s how developers structure their code and their thinking.
CSS supports splitting styles across multiple files. This works for simple webpages — what CSS was originally designed for — but is impractical for component-based SPAs, because every <link rel="stylesheet"> blocks rendering. More files means more blocking requests.
Developers are forced into a losing choice: keep styles modular and accept slow page loads, or collapse them into monolithic bundles that load fast but abandon file-level organization — then depend on build tools to manage the resulting mess. Either path means more effort, worse code structure, and tooling dependencies that wouldn’t exist if the platform supported non-blocking stylesheet loading.
The platform had a closer attempt. HTML5 specified a scoped attribute on <style> — styles scoped to a specified element’s subtree. Firefox shipped it in version 21. In 2016, Domenic Denicola filed the removal:
Domenic Denicola
It seems shadow DOM and stylesheets restricted to a shadow tree ends up solving more of the real-world problems developers are faced with.
He followed this up with the familiar “no vendors” trope, parroting Hickson from the depends thread seven years earlier. Apparently “no vendors” is the same thing as “no use case” in his mind. Or maybe it’s post hoc rationalization for the simple fact that only Firefox implemented it. Shadow DOM is a component isolation model — it solves style encapsulation, not style loading. Nevermind that developers and browser engineers wanted scoped — they’re not vendors, and besides, Domenic knows the best way to load scoped CSS modules: Shadow DOM. The reinstatement request was closed as a duplicate of @scope, which is a different feature entirely.
Hickson acknowledged in 2012 that <link scoped> — external files, not inline — was the right design if the use case warranted it. It was never specified. Seven years later, the CSS Working Group shipped @scope — selector containment, nothing for loading. CSS still has no mechanism for non-blocking, file-level module loading.
depends and defer were 75% of the complete solution. Add scoped on <link> and developers would have had declarative dependency loading, non-blocking stylesheets, and component-scoped styles — all in HTML, all visible at parse time, no build step. Three attributes. Instead, the platform killed scoped, never specified <link scoped>, and left CSS with no loading story at all.
This is what HTML was designed to be. The thoughts that went into hypertext in 1989 match exactly what depends solves. Hypertext is a graph — HTML hides that complexity behind <a href>. depends does the same thing for resource loading: a graph declared as a list of IDs. Simple, declarative, and powerful. No tree traversal, no recursive fetch, no build tooling. By keeping things simple, Berners-Lee encouraged others to build upon his ideas. depends follows that principle — developers don’t need to understand dependency graphs to use one.
The defer attribute on <link> in the 2009 proposal would have solved non-blocking CSS directly. Instead, Google’s own web.dev performance guide recommends this “advanced performance technique that can improve performance”:
<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>— a hack that uses inline JavaScript in a <link> element, a <noscript> fallback, and rel="preload" — which fetches asynchronously but does so at the highest priority, the exact opposite of deferring.
Still Expanding, Seventeen Years In
As of January 2026, Chromium is shipping support for as="style" and as="json" in modulepreload — because CSS and JSON modules can be imported but historically could not be preloaded. The intent to ship calls it a “functionality gap.” Mozilla and WebKit both had no signal at the time of filing. Every new module type requires a new as= value, a new spec change, a new round of browser adoption. A depends attribute referencing element IDs would have been content-type agnostic — it works for scripts, stylesheets, JSON, or anything else loadable by a <script> or <link> element, without per-type spec work.
For a broader view of the damage caused by shipping a module system without a loading mechanism, see joepie91’s “ES Modules are terrible, actually” — 220 stars, years of detailed technical debate, and a comment thread that reads like a support group for developers who’ve lost hours to the CJS/ESM split.
The Better Design That Was Rejected
In February 2009, I submitted a proposal to the WHATWG mailing list: put the dependency graph in HTML.
<script depends="a b c"></script>Where depends is a space-separated list of element IDs. The browser resolves the graph. One declaration, in markup, visible to the pre-parser before any JS executes.
Two attributes covered the dependency-loading problem. depends on <script> declared which resources a script needs before execution. defer on <link> allowed stylesheets to load without blocking rendering. If a script doesn’t list a stylesheet in depends, the browser knows it doesn’t need that stylesheet’s data — no blocking required.
Because depends references element IDs — not script IDs or stylesheet IDs — it works for any resource type. Scripts, stylesheets, fonts, images, video — anything with an id and an href or src can be a dependency:
<link id="ui-font" rel="preload" href="inter.woff2" as="font" defer>
<link id="ui-style" rel="stylesheet" href="ui.css" defer>
<script id="ui" src="ui.js" depends="ui-style ui-font"></script>
<script src="app.js" depends="ui"></script>The browser reads the graph at parse time, schedules all fetches in parallel, and resolves the execution order. No bundler required. No recursive fetch. No build step. Developers don’t need to know what a dependency graph is, or how BFS/DFS traversal works — they just declare: “this script needs those resources, and those resources shouldn’t block initial page load.”
Browsers block scripts on preceding stylesheets for a real reason: CSSOM consistency. A script calling getComputedStyle or reading offsetLeft needs accurate style data. The proposal didn’t ask browsers to break that guarantee — it gave developers a way to declare it. If a script needs style data, say so with depends. If it doesn’t, don’t list the stylesheet. The browser still enforces the constraint. The developer simply declares it.
ES modules solve language-level dependency semantics. depends solves HTML-level resource scheduling. They’re complementary — a script loaded via depends can contain import statements. A stylesheet loaded via defer can be required by a script via depends. Cross-resource dependencies, declared in one place.
The architectural difference is where the graph becomes visible:
Current: Proposed (2009):
HTML HTML
↓ ↓
load root module dependency graph already declared
↓ ↓
parse JS schedule all fetches
↓ ↓
discover dependency graph fetch in parallel
↓ ↓
schedule loads execute in declared orderThe current architecture requires round trips to discover what to download. The proposed architecture exposes the dependency graph to the browser’s networking layer at parse time, before any JS is fetched.
This wasn’t theoretical. I provided test pages with timing data. A linked stylesheet delayed by five seconds produced contentLoaded and onloadFired values of ~5101ms — the entire page waited for one stylesheet. HTTP waterfall data from Firefox 3.0 showed that a script in the <body> wasn’t even requested until a <head> stylesheet completed, eight seconds after the initial page load:
+---------------------+-------------------------------+
| req + HTTP date |
+---------------------+-------------------------------+
| link-external.html | Tue, 10 Feb 2009 07:01:13 GMT |
| example.js?top | Tue, 10 Feb 2009 07:01:13 GMT |
| delay.jsp?ct=text...| Tue, 10 Feb 2009 07:01:13 GMT |
| example.js?bottom | Tue, 10 Feb 2009 07:01:22 GMT |
+---------------------+-------------------------------+The last request — a script before the closing </body> tag — was delayed eight seconds. The browser waited for a stylesheet in <head> to finish before it would even fetch a script in <body>.
The spec’s fetch a modulepreload module script graph algorithm exists today precisely because the HTML doesn’t express the graph. The browser walks it at fetch time because the markup never declared it. A depends attribute would have made the browser’s job explicit and the developer’s intent unambiguous.
What Happened to the Proposal
The thread is public. Here’s what it shows.
Ian Hickson, the WHATWG spec editor, dismissed the problem outright:
“Browsers are already allowed to not block on those elements.”
The spec permitted non-blocking behavior. Browsers didn’t do it. Developers had no way to control it.
Jonas Sicking, a Mozilla engineer, immediately contradicted Hickson. In Gecko, the browser blocks script execution until all preceding stylesheets finish loading — because scripts might call getComputedStyle or read offsetLeft:
“We have found that some sites break if we just use whatever style data happens to have loaded at that point, rather than ensuring that all stylesheets have been parsed and applied.”
When I responded with test data, concrete use cases, and worked examples of depends and defer, Hickson’s objection shifted:
“This seems like an inordinate amount of complexity for something that can just work already.”
The problem went from “doesn’t exist” to “too complex to solve” in one exchange.
Boris Zbarsky of Mozilla engaged more substantively. He acknowledged the technical merit:
“I would be fine with a way to flag scripts with that information.”
But he argued that any new attribute would produce divergent behavior between old and new browsers. If a script declares via depends that it doesn’t need a preceding stylesheet, new browsers skip the blocking while old ones still block:
“I don’t think anything would solve the problem for browsers today.”
Applied consistently, this reasoning blocks any new attribute from ever being specified. Every new HTML attribute produces divergent behavior between supporting and non-supporting browsers. That’s what new features are.
The Structural Problem
WHATWG proposals advance when a browser vendor commits to implementing them. Proposals without that commitment get filtered through different questions: “Is this already possible in theory?” and “Would existing browsers break?” Both tests favor the status quo. The proposal had no vendor backing, and without that, it went nowhere.
How the Graph Got Lost Between Two Specs
Five years later, TC39 designed ES6 modules with a programmatic Loader — a five-stage pipeline (Locate, Fetch, Translate, Instantiate, Link) that would have given the browser access to the dependency graph. The Loader’s instantiate stage returned a structure that declared dependencies before execution (sound familiar?):
instantiate: function(load) {
return {
deps: ['some', 'dependencies'],
execute: function(depA, depB) {
return new Module({ /* exports */ });
}
};
}An explicit dependency list, declared before execution, so the loader could schedule all fetches immediately. The same architectural requirement that depends addressed in HTML: the system must know the graph before execution to schedule network requests efficiently.
In September 2014, TC39 cut the Loader from the spec. The committee kept the import/export syntax and handed the loading mechanism to the WHATWG as a separate “living standard” Loader project. That project stalled and was effectively abandoned by 2018.
The dependency graph ended up locked inside JS import statements, invisible to the HTML parser — and addressing only JavaScript, leaving the CSS Working Group to solve loading on their own (look how that turned out). The loading spec that was supposed to bridge the two layers was never completed.
AMD and RequireJS are massive projects. They support stylesheet and font loading through plugins and integration with external libraries like Web Font Loader — more “best practices” kludges that rely on browser hacks, and exist to address the barndoor-wide gaps the spec authors failed to close. These tools remain in widespread use because the platform never solved the problem natively. Today’s build tools extract the module dependency graph and inject <link rel="modulepreload"> elements so browsers can fetch modules in parallel.
The web platform provides preload, prefetch, fetchpriority, loading="lazy", and font-display — but those are resource hints and fetch-priority controls, not dependency declarations. They influence when and how a resource is fetched, but they do not express relationships between scripts and other resources. JS import statements express dependency relationships between scripts and other resource types. modulepreload is an afterthought to influence fetch priority behavior of those scripts. There is no web platform API to declare:
script → stylesheet
script → font
script → image
script → JSONThese are the relationships that matter for resource scheduling, and depends expressed all of them. The current platform mixes three unrelated mechanisms:
dependency discovery JS imports, modulepreload hints
fetch priority preload, fetchpriority, lazy loading
style containment @scope, shadow DOMOf my proposals, depends addressed the first, defer on <link> addressed the second. The scoped attribute addressed the third. depends on <script> does what modulepreload does — and more — more simply, more expressively, with less code. The build tool is the integration layer between specs that never coordinated.
Seventeen years of attempts to solve the same problem:
- 2009 —
dependsanddeferon HTML elements. Dismissed within hours, no design exploration. - 2012 —
<style scoped>specified in HTML5, implemented in Firefox. Hickson acknowledged that<link scoped>(external files) was the right design. Never specified. - 2014 — ES6 Loader with
depsarray. Cut from the spec, handed to WHATWG, abandoned. - 2016 —
<style scoped>removed from the spec by Domenic Denicola. Shadow DOM cited as the replacement. - 2018 —
modulepreloadships in Chrome. JS-only, no validation, requires build tooling. Five years before a second browser implements it. - 2019 —
loading="lazy"ships for images and iframes. The platform can add declarative loading attributes when vendors want to. - 2023 —
@scopeships. Selector containment. Nothing for loading. - 2026 —
modulepreloadreaches Baseline Widely Available. Chromium addsas="style"andas="json"tomodulepreload— because import-type modules for CSS and JSON can be imported but not preloaded. Browser support for CSS and JSON import types remains spotty.
Two designs declared a flexible, resource-agnostic graph before execution — depends and the ES6 Loader deps array — killed. The one attempt at declarative stylesheet scoping — <style scoped> — also killed. Everything else is either a workaround or addresses the wrong layer.
What Happened to Declarative Dependency Loading
My proposal was dismissed without vendor backing. The ES6 Loader was cut. Both declared the graph before execution. Neither survived.
modulepreload is an afterthought — a fetch-priority hint bolted onto <link> to partially address the waterfall that JS import statements created. It duplicates the dependency graph across HTML and JS with no validation layer between them. It took five years to reach cross-browser support — reaching “Baseline Widely Available” only in March 2026 — the same kind of cross-browser gap Zbarsky used to argue against depends in 2009. The platform still penalizes CSS modularity at the loading level. Build tools fill the gap for JavaScript; everything else is left to hacks and workarounds.
The proposal put the graph in HTML, where the browser could act on it at parse time — before fetching any resource, for any resource type. And it did so simply enough that developers didn’t need to think in terms of graphs or trees — just: “this script needs those styles, and they shouldn’t block initial page load.” The platform put the graph in JS, lost the loading spec between two committees, and compensated with a hint mechanism that requires tooling to maintain.
The thread is still there. The test pages are gone, but the arguments — and who made them — are preserved.
The original WHATWG mailing list thread: [whatwg] defer on style, depends — February 8, 2009