So far in this series, we've followed the evolution of the web one problem at a time.

We started with a web made entirely of static HTML pages. To create pages dynamically, servers began generating HTML on demand using technologies such as CGI.

That solved one problem, but browsers were still passive. Every interaction required a trip back to the server. That's why Javascript was created, allowing browsers to run code and respond immediately to user actions.

Later, AJAX made another major leap forward by allowing browsers to communicate with servers in the background, updating parts of a page without requiring a full page reload. We also saw how jQuery made that new way of building websites much easier by hiding browser differences behind a simple, consistent API.

Even then, one limitation remained.

Although parts of a page could now update independently, navigating to another page still meant downloading an entirely new HTML document and rebuilding the interface from scratch.

That limitation led to the next major evolution of the web: the Single-Page Application (SPA), a new architecture that kept the browser on the same page while Javascript updated the interface.

Confession: When I first heard the term Single-Page Application, I assumed it literally meant a website made from a single HTML page. Technically... that's not completely wrong, but it's also missing the point.

The "single page" isn't about cramming your entire application into one enormous HTML file. It's about the browser staying on the same page while Javascript updates the interface as you navigate.

If you were expecting one gigantic index.html containing your entire application... you're definitely not the only one.

The page reload problem

When the web was originally designed, websites were exactly what the name suggested: pages.

Each click usually triggered a familiar sequence of events.

User clicks a link
        ↓
Browser requests a new page
        ↓
Server returns an HTML document
        ↓
Browser replaces the current page
        ↓
Everything loads again

For years, this was completely normal.

Reading a blog, browsing documentation, or shopping online didn't require a highly interactive interface. Waiting for the next page to load was simply how the web worked.

However, expectations began to change.

As web applications became more capable, users' expectations changed too.

People wanted to open a menu, switch between messages, browse products, or move between different sections of an application without seeing the entire page disappear and reload each time.

The traditional request-response model started to feel increasingly slow and disruptive.

Why AJAX wasn't enough

AJAX was a huge step forward. Instead of refreshing the entire page, browsers could request only the data they needed and update a small part of the interface. Search suggestions could appear as you typed, shopping carts could update instantly, new chat messages could arrive automatically, and comments could be posted without interrupting what you were reading.

But AJAX solved only part of the problem. It improved individual interactions without changing how websites were fundamentally built. Each page was still a separate HTML document served by the server.

In a traditional Multi-Page Application (MPA), clicking a navigation link typically requested a completely new HTML document. The browser discarded the current page, downloaded a new one, reloaded the application's Javascript and CSS, and started everything again from scratch.

Developers had made websites far more interactive, but the web was still built around navigating from one page to another. As users began expecting web applications to behave more like desktop software, that traditional page-by-page model started to show its age.

Single-Page Applications arrive

A Single-Page Application (SPA) can contain dozens or even hundreds of different screens. The "single page" refers to the browser loading one HTML document initially, while Javascript takes over navigation using client-side routing and updates the interface without performing a full page reload.

Instead of requesting a new page for every navigation, the browser keeps the application running and asks the server only for the data it needs.

The difference is easier to understand visually.

# Traditional Multi-Page Application (MPA)

Click
   ↓
Server returns a new HTML page
   ↓
Browser replaces everything

---

# Single-Page Application (SPA)

Application is already loaded
          ↓
User clicks a link
          ↓
Javascript updates the interface
          ↓
Server returns only the required data (if needed)

From the user's perspective, the experience became dramatically smoother. Navigation felt almost instant, animations remained uninterrupted, and the application could preserve its state while moving between different screens.

For the first time, websites no longer behaved like a collection of separate pages. They felt like a single, continuous application running inside the browser.

This architectural shift paved the way for frameworks such as React, Angular, and Vue, which embraced this new model and made it practical to build increasingly complex web applications.

The trade-offs

Like every major shift in web development, Single-Page Applications solved one set of problems while introducing new ones.

Because much more of the application now lived in the browser, the initial download often became significantly larger. Instead of receiving a small HTML page for each request, users typically downloaded a large Javascript bundle before the application became fully interactive.

Building SPAs also increased complexity for developers. Client-side routing, state management, authentication, browser history, and data synchronization all became responsibilities of the application instead of the server.

Search engine optimization (SEO) was another challenge in the early days of SPAs. Many applications initially sent the browser a nearly empty HTML document containing little more than a root element, with Javascript responsible for fetching data and rendering the entire interface afterwards.

Early search engines often indexed only that initial HTML, meaning they couldn't reliably see the content users eventually saw in their browsers. As a result, some SPA websites struggled to appear in search results.

Over time, both search engines and web frameworks improved. Techniques such as Server-Side Rendering (SSR) and Static Site Generation (SSG) made it possible to send fully rendered HTML from the start, allowing search engines to crawl and index pages much more reliably.

The beginning of the next chapter

Single-Page Applications changed how websites were built, but they didn't solve every problem.

As applications grew larger, managing hundreds of components, events, and DOM updates with libraries like jQuery became increasingly difficult. Codebases became harder to organize, maintain, and reason about. Avoiding page reloads was no longer the biggest challenge. Building and maintaining large client-side applications was.

That challenge led to the rise of modern frontend frameworks, beginning with React, which introduced a new way of thinking about building user interfaces.

Key takeaways

  • Single-Page Applications changed the web by loading a single HTML document and updating the interface with Javascript instead of reloading entire pages.
  • While AJAX made individual interactions more dynamic, SPAs rethought the overall architecture of web applications.
  • The complexity of building large SPAs eventually led to the development of frameworks like React, which provided better ways to organize and manage growing applications.

Frequently asked questions

What is a Single-Page Application?

A Single-Page Application (SPA) is a web application that loads a single HTML document initially and uses Javascript to update the interface as users interact with it. Instead of requesting a new page for every navigation, the browser updates the existing page and fetches only the data it needs.

Yes. Single-Page Applications are still widely used for applications where users spend a lot of time interacting with the interface, such as email clients, project management tools, messaging applications, dashboards, and online editors. Although developers now have more architectural choices, the SPA model continues to power many modern web applications.

Can Single-Page Applications be SEO friendly?

Not necessarily. Early SPAs often struggled with SEO because search engines had difficulty indexing content rendered entirely with Javascript. Today, frameworks like Next.js support server-side rendering and static site generation, allowing developers to build SPA-like experiences while maintaining excellent SEO.

Is React a Single-Page Application?

No. React is a Javascript library for building user interfaces, not an application architecture.

However, React is commonly used to build Single-Page Applications, which is why the two concepts are often associated. React can also be used to build server-rendered websites, static sites, or individual interactive components within traditional multi-page applications.

Explore the series

I wasn't building websites when the web was just HTML or when Javascript didn't exist. Like many developers, I learned modern frameworks first and only later became curious about how we got here.

This series is my way of connecting those dots. By looking back at the problems developers faced and the solutions they created, it becomes much easier to understand why today's tools exist and why the web evolved the way it did.