Javascript As a Progressive Enhancement

How We Got Here

Most of us know the history, but just in case, here's a brief recap. Tim Berners-Lee developed HTML and built the first website in 1991 to share documents over a distributed network. CSS followed in 1996, adding a suggested style to those documents. Brendan Eich created JavaScript in 1995 to introduce interactivity to web pages, and it became the ECMA-262 standard in 1997.

Initially, web development followed a simple structure: HTML for content, CSS for styling, and JavaScript for interactions. Back-end languages like PHP handled server-side logic, data persistence, and code splitting. Aside from browser compatibility concerns, developers shared a common approach to building the web. Then, the iPhone arrived.

Smaller screens, lower bandwidth, and slower connections forced us to rethink web development. Responsive design became essential, as did reducing full-page reloads. Meanwhile, native apps took advantage of device capabilities and often worked offline. Product managers turned to web developers and asked, "Can you make it work like the app?" The answer was... Yes? Enter modern JavaScript.

The Problem

Websites were never intended to function as native applications. The web was designed for shareable documents—a digital extension of print media. Browsers are built to search and display these documents, prioritizing accessibility and user preferences. Users can adjust font sizes, disable JavaScript, or rely on screen readers to consume content.

As web development shifted toward JavaScript-first applications, new challenges emerged. JavaScript had to replicate built-in browser behaviors like page history and scroll positions. It also raised SEO concerns when browsers couldn’t crawl content because JavaScript was responsible for building the page. Frameworks and libraries emerged to solve these issues—SSR being a prime example. But think about it: we're now using JavaScript to generate HTML on the server, only to serve it as plain HTML. Have we lost the plot? Yes... Yes, we have.

What Are We Using JavaScript For Again?

Most of us aren't building complex HTML Canvas games. Instead, we typically use JavaScript for:

• Adding interactivity (the traditional way).
• Handling animations and visual updates.
• Code splitting (structuring HTML components).
• Sharing and updating data dynamically.

These use cases make sense, but we often forget that the web evolves. Many JavaScript solutions become obsolete or overkill as native features emerge. Here are a few examples:

• Interactions: The native popover attribute eliminates the need for JavaScript-driven modals and dropdowns.
• Animations: CSS now supports robust animations, including page transitions.
• Code splitting: This has long been achievable with back-end languages like PHP, but Static Site Generators (SSGs) such as Jekyll, Hugo, and 11ty now provide similar benefits without requiring a traditional server.
• Data updates: JavaScript is essential for real-time updates—but how often do we actually need data to update live?

When You Do Need JavaScript

While many features can now be handled natively, JavaScript remains necessary in some cases:

• Updating site data without reloading the page.
• Working with an API that relies on JavaScript.
• Running in a JavaScript environment like Node, Deno, or Bun.
• Making a web app behave like its mobile counterpart.

The last point is particularly tricky. No matter how well you replicate a native experience with Service Workers, device APIs, and front-end routing, there’s one thing you can’t control—users disabling JavaScript. You might think, “Who even does that?” But some do, often for security or privacy reasons. For example, the Brave browser provides a simple toggle in the URL bar to disable scripts. More importantly, we need to step back and consider what the web was designed for. At its core, the web is built for documents—everything else is just an enhancement.

So...

If the web is fundamentally about documents, we should build with that in mind:

• Ensure documents are accessible and readable with or without JavaScript.
• Use JavaScript as an enhancement, not a requirement.
• Leverage native browser features whenever possible.
• If JavaScript is essential, clearly communicate that to users.

Most of us aren’t building complex web apps or games—we’re creating content-driven documents with styling and light interaction. Thankfully, browsers keep evolving, reducing our reliance on JavaScript.

And just to be clear—I like JavaScript. I’ve spent over a decade using it on both the client and server. But the key is using the right tool for the job. Build from simple to complex, not the other way around. And when you do need JavaScript (on the web), make sure your core content still works without it.

JavaScript should enhance the web—not define it.