loke.dev
Header image for What Nobody Tells You About the ESM Waterfall: Why Your 'Build-Free' App Is Silently Loading in Slow Motion

What Nobody Tells You About the ESM Waterfall: Why Your 'Build-Free' App Is Silently Loading in Slow Motion

Native ESM promises a future without complex bundlers, but deep dependency trees create a sequential loading bottleneck that silently destroys your Largest Contentful Paint.

· 5 min read

The dream of the "no-build" web is a beautiful lie we tell ourselves while we wait four seconds for a single button to become interactive. We were promised that native EcmaScript Modules (ESM) would kill the complexity of Webpack and Vite, letting us ship raw JS files directly to the browser. But here’s the cold, hard truth: unless your app consists of exactly three files, native ESM is likely destroying your performance through a thousand tiny network cuts.

The "Discovery" Problem

When you bundle an app, the bundler crawls your dependency graph ahead of time. It knows that App.js needs Button.js, which needs Icon.js. It glues them together into one (or a few) files.

When you go "build-free" with native ESM, the browser is flying blind.

Imagine this simple setup:

// main.js
import { initApp } from './app.js';
initApp();

// app.js
import { theme } from './utils/theme.js';
import { Sidebar } from './components/Sidebar.js';
// ... rest of the logic

// components/Sidebar.js
import { Nav } from './Nav.js';
import { UserProfile } from './UserProfile.js';

In a bundled world, the browser gets one file and starts executing. In the native ESM world, a "Waterfall" begins:
1. Browser downloads index.html.
2. Browser sees <script type="module" src="main.js">. It starts downloading.
3. Wait. The browser finishes main.js, parses it, and realizes: "Oh, I need app.js."
4. Wait. It downloads app.js, parses it, and sees it needs theme.js and Sidebar.js.
5. Wait. It fetches those... then realizes Sidebar.js needs Nav.js.

This is sequential discovery. Even with a 50ms roundtrip latency, a dependency tree 10 layers deep adds half a second of "doing nothing" before the first line of actual UI logic runs. On a 4G connection? You’re looking at several seconds of a white screen.

"But I have HTTP/2 and HTTP/3!"

I hear this a lot. "HTTP/2 has multiplexing! It can download 100 files at once!"

Yes, HTTP/2 is great at downloading multiple files *at the same time*, but it cannot download what it doesn't know exists. The browser cannot request Nav.js until it has finished downloading and parsing Sidebar.js. Multiplexing solves the congestion problem; it does nothing for the discovery problem.

The Invisible LCP Killer

Your Largest Contentful Paint (LCP) is the most sensitive victim here. If your main hero image depends on a component that is 5 levels deep in an ESM tree, that image won't even *begin* to load until the browser has finished five sequential hops of JS parsing.

Look at how this manifests in a real-world dependency like a small utility library:

// Internal dependency hell
import { map } from 'https://cdn.skypack.dev/lodash-es/map.js';
import { filter } from 'https://cdn.skypack.dev/lodash-es/filter.js';
// Each of these might have their own sub-imports...

If you import 20 tiny modules from a CDN like Skypack or ESM.sh without a bundle step, you aren't just making 20 requests; you're often creating a chain of dependencies that would make a Victorian watchmaker dizzy.

How to Fix It (Without Going Back to Webpack Hell)

If you're committed to the ESM life, you have a few tools to fight the waterfall.

1. Module Preloading (The Manual Way)

You can tell the browser about your deep dependencies before it even parses the parent files. The <link rel="modulepreload"> tag is your best friend here.

<head>
  <!-- Preload the entry point -->
  <link rel="modulepreload" href="/src/main.js">
  <!-- Preload the deep dependencies so they are ready immediately -->
  <link rel="modulepreload" href="/src/app.js">
  <link rel="symbolic" href="/src/components/Sidebar.js">
  <link rel="modulepreload" href="/src/utils/theme.js">
</head>

By doing this, the browser kicks off the downloads in parallel immediately. The catch? You have to maintain this list manually, which is a nightmare.

2. Import Maps

Import maps allow you to map "bare specifiers" (like import { logic } from 'utils') to specific URLs. While they don't solve the waterfall by themselves, they work beautifully with preloading to ensure the browser knows exactly where everything is.

<script type="importmap">
{
  "imports": {
    "app": "/src/app.js",
    "theme": "/src/utils/theme.js"
  }
}
</script>

3. "Smart" CDNs

Some CDNs like esm.sh offer a ?bundle query parameter. This is a bit of a cheat code. It allows you to request a module and tells the CDN to bundle all its sub-dependencies into a single file on the fly.

// Instead of 50 requests for lodash modules:
import { map, filter, reduce } from 'https://esm.sh/lodash-es?bundle';

The Pragmatic Middle Ground

I love the simplicity of no-build. I really do. But for production apps, the "No-Build" movement is often just "Deferred-Build." You're pushing the computation (parsing and discovery) onto your user's CPU and network instead of doing it once on your CI server.

The most successful "modern" setups I've seen use a Hybrid Approach:
- Development: Use native ESM (via Vite or similar) for instant HMR.
- Production: Perform a light bundle to flatten the tree to 1 or 2 levels deep.

If you insist on going pure ESM in production, keep your dependency tree flat. If A needs B, and B needs C, try to refactor so A needs both B and C directly. It feels less "elegant" from a code structure perspective, but your LCP will thank you.

Stop ignoring the network tab. Open it up, throttle it to "Fast 3G," and watch your app load. If you see a staircase pattern in your JS files, you’ve got a waterfall problem. And no amount of "clean code" is worth a user walking away because your imports took too long to say hello.