Understanding SPAs and their shortcomings

In some ways it's difficult to define exactly what an SPA is. There's the more classic definition and then there's the more modern versions depending on who you ask. If we break it up into two parts we can define SPA in a way that allows us to also talk about the modern approaches. The classic definition usually includes what the SPA is trying to do, and how it's technically implemented:

1. What an SPA is trying to do: The original idea behind an SPA was to preserve JavaScript state by not doing a refresh. Each new page and URL change will load the next page instantly because you've downloaded all the JavaScript for every page ahead of time (known as the bundle). SPAs are trying to feel faster since the instructions for the UI are pre-downloaded.

2. SPA implementation details: Normally an SPA is achieved with 100% Client Side Rendering. We serve a mostly empty HTML file, then the JavaScript bundle comes next which is big because it has all the instructions for every page, then the page you're on might need data-fetching. This means three serial requests before the use sees anything:

GET /page.html   ▓▓▓▓▓▓
GET /bundle.js         ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
GET /api/users                             ▓▓▓▓▓▓▓▓

A quick detail about Client Side Rendering (CSR). Sometimes CSR and SPA seem interchangeable since SPAs use CSR as their mode for making UI, but consider that CSR is a more broad term that means any form of using JavaScript on the client to render UI. So jQuery in 2007 making some DOM was doing CSR.

Problems with SPAs

When people start talking about the tradeoffs of using a SPA, the downsides mentioned are often "not good for SEO" and "not as good for performance as SSR sites". I find those to be less objective so we're not going to focus there.

I'm going to focus on the scaling issues of SPAs that are more based in fact.

As an SPA grows in pages and UI, it will grow in bundle size. The common mitigation for this is code-splitting which means we break the bundle up into parts and download only what we need (called lazy loading). This is actually very easy to do with modern bundlers. The lazy loading part is where we see the problems as it pertains to data fetching.

Consider this scenario: Without code splitting, you have a large bundle but when you want navigate from one page to the next, you have all instructions to show the next page quickly. You just need data so you do some sort of data-fetching strategy in the component using useEffect or useQuery.

Now consider what happens with code splitting and lazy loading: When you want to navigate to this second page, you don't have the JS code for it yet. When the user goes to that page, we start the download process. When the JS code arrives, we now start to render the page which has data-fetching inside the component. This means we'll then start to fetch data for that page after we already had to wait for the JS in the first place. Here's a contrast of the two scenarios:

// SPA without code splitting
// User navigates to page 2 which needs user data
GET /api/users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

// SPA with code splitting and lazy loading
// User navigates to page 2 which needs JS first, then can get data
GET /second-bundle.js    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
GET /api/users                          ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

Doing code-splitting usually means you'll now have to do two serial requests for each page you go to. I wrote in length in a post called SPA Lazy Loading Pitfalls

The solution to the problem? Don't do data-fetching within the components if the component is a "Page". See the blog post for examples on how you can use React Router Loaders (in v6.4+) to fix this issue. The official React recommendation on data fetching even calls this issue out and mentions React Router 6.4 as a fix

The framework twist on SPAs

Frameworks like Next and React Router Framework (Formerly Remix) do SSR. Any page you visit will serve fully formed HTML. However, when you go from one page to the next, the next page is a client-side navigation without a refresh (just like an SPA). The framework takes care of the lazy loading and code-splitting for you in a way that doesn't have the same pitfalls as the home-grown approach to SPAs.

Does that mean frameworks are SPAs too? If we ditch the "implementation detail" of what it originally meant to be an SPA and just consider "What an SPA is trying to do", then I would say the frameworks are offering us the best aspect of SPAs while leaving behind the problems. I actually refer to the frameworks as being more of a hybrid of SPAs and Multi-Page Apps (MPAs) that are server rendered.