How Much JavaScript Does a Website Really Need?

The useful amount of JavaScript is not zero and it is not “whatever the framework ships.” It is the amount required for the page to do its job.

A map, editor, dashboard, or live chat needs behaviour and state. A blog article needs to show text, images, and links. Treating those pages as the same engineering problem creates a lot of work for both the developer and the visitor.

Start with what the page must do

The job of an article might be:

show text
show images
provide links

None of that requires JavaScript.

A product configurator may need:

state
live price updates
API requests
complex interaction

That probably does. The feature requirements should lead to the technology, rather than a chosen stack searching for something to render.

Check what HTML already provides

A disclosure can begin with native elements:

<details>
  <summary>More information</summary>
  <p>...</p>
</details>

A modal has its own element:

<dialog>
  ...
</dialog>

So does a lightweight popover:

<button popovertarget="menu">
  Menu
</button>

<div id="menu" popover>
  ...
</div>

Forms already include input types, autocomplete, and validation primitives. These features may not cover a product’s complete design, but they are a stronger starting point than recreating the underlying interaction from <div> elements.

CSS handles layout and several common interface behaviours too:

grid-template-columns:
  repeat(auto-fit, minmax(18rem, 1fr));

position: sticky;
top: 0;

@media (prefers-color-scheme: dark) {
  ...
}

scroll-snap-type: x mandatory;

None needs a resize or scroll listener.

JavaScript should earn its execution time

Fetching data, managing application state, complex filtering, client-side search, live calculations, and real-time updates are good reasons to use JavaScript. The goal is useful JavaScript, not an artificially script-free site.

Its cost is more than the transferred bytes:

download
↓
parse
↓
compile
↓
execute
↓
maybe update DOM

That is why 100 KB of JavaScript is not equivalent to a 100 KB image, especially on a slower phone.

Third-party scripts count too. A site with 20 KB of its own code can still run analytics, advertising, chat, social widgets, and A/B testing. The visitor’s processor does not care which company owns the file.

Small glue code is not the enemy

This is a perfectly reasonable use of JavaScript:

button.addEventListener("click", () => {
  dialog.showModal();
});

It connects a control to native dialog behaviour. That is different from shipping an application runtime for a page that mostly displays an article.

Frameworks are also reasonable for large applications where their structure helps a team manage real complexity. A company homepage and an online banking dashboard simply do not have the same needs.

Measure the code visitors actually run

DevTools can show transferred JavaScript, main-thread time, unused code, and long tasks. If a large bundle exists for one small menu, question the bundle. If it powers the product’s core interaction and performs well on representative devices, its size has context.

My preferred order is:

HTML
↓
CSS
↓
small JavaScript
↓
larger library
↓
framework

I move down only when the behaviour needs it. “Is JavaScript good?” is not a useful architecture question. “Does this code provide enough value to justify its download, execution, and maintenance?” usually is.