Question Details

No question body available.

Tags

architecture node.js front-end backend single-page-apps

Answers (3)

Accepted Answer Available
Accepted Answer
November 4, 2025 Score: 7 Rep: 46,830 Quality: Expert Completeness: 70%

The heart and soul of a single page application is just that: a single page; one full page load. It means avoiding that old, clunky GET-POST-Redirect architecture where every user action redraws the entire page; so, ultimately, the answer to this question depends heavily on how exactly you implement server-side rendering.

If your backend endpoints return full HTML documents, then you have that old, clunky GET-POST-Redirect feel; not a single page application.

If your backend endpoints return partial documents or HTML snippets, then you have one full page load, but user actions only redraw certain regions of the page. I would consider that a single page application because you avoid full page turns.

Next.js describes what it calls a "strict SPA":

  • Client-side rendering
  • No full-page reloads

They further elaborate:

Next.js can start as a static site or even a strict SPA where everything is rendered client-side. If your project grows, Next.js allows you to progressively add more server features (e.g. React Server Components, Server Actions, and more) as needed. (emphasis: mine)

Source: https://nextjs.org/docs/app/guides/single-page-applications#why-use-nextjs-for-spas

This leads me to believe that even the framework authors believe the SPA architectural style exists on a spectrum. Note that this isn't a completely foreign concept, that an SPA can utilize server-side rendering. The Blazor framework in .NET offers different rendering modes from purely client side, to a hybrid of the two:

  • Static Server — all rendering happens on the server (think: old school GET-POST-Redirect)
  • Interactive Server using the Blazor framework — probably rendering HTML snippets and returning them to the client.
  • Interactive WebAssembly — straight client side rendering.
  • Interactive Auto — "Interactive SSR using Blazor Server initially and then CSR on subsequent visits after the Blazor bundle is downloaded."

This C-sharp Corner article seems to lend additional credence to a hybrid approach for a single page application when a framework offers frontend and backend rendering options:

And folks, all that talk about SSR (Server-Side Rendering) boils down to this. It's a Blazor hosting model where the application runs on the server, and UI updates are sent to the client via a SignalR connection.

Rikam Palkar, What makes Blazor SPA and how does Server-Side Rendering works with Blazor's new Web App

As long as you avoid unloading the current page and loading a new page with every user action, you can call it a single page application when utilizing server side rendering.

November 3, 2025 Score: 3 Rep: 139,531 Quality: Medium Completeness: 60%

Well, sort of.

After all, nothing in the definition of an SPA mandates the client-side rendering. And if it would, it wouldn't make too much sense.

Imagine a simplistic application that displays a counter of the number of times users clicked on it. When you open the web application, you see a value, say, 9 524. You click twice, and the value changes to 9 526. Then it switches to 9 527, because some other user clicked on the counter. When it reaches 1 000 000, it is shown in a different style.

Now, there are several ways to approach this.

For instance, the messages going through Server-sent events (SSE) could contain a simple numeric value 9527 for 9 527. Then, it would be up to the client to format the number, and also adjust the visual appearance of the counter once the value is equal to one million.

As an alternative, SSE message can contain a formatted number 9 527. And also a boolean value indicating whether an alternative style should be used. Now it's the server that decides whether the magical value is one million or something else, and it's the server that decides that a space is being used as a thousands separator. Definitively, the server does part of the rendering here!

Or the message can be:

9 527
. Does it make your app suddenly not SPA? Not really. You haven't refreshed the page. But the rendering of a part of the page still happens on server.

Now, what should you be wondering is not whether your app is an SPA or not per se, but rather what level of server-side rendering you should use, given your current requirements and constraints.

Back to the example with the counter, all three approaches are valid, and each has its benefits and drawbacks. The last one, for instance, is a bit intensive in terms of bandwidth, but it also makes the application itself extremely simple: grab the message, put it verbatim on page. The first one, on the other hand, saves you bandwidth if you expect to receive a lot of messages, but forces you to implement quite a bit of logic on client side. The second approach simplifies the client side logic a bit, but doesn't handle well the internationalization: thousands separator is not the same from one culture to another.

November 4, 2025 Score: -2 Rep: 1 Quality: Low Completeness: 50%

My question concerns Next.js: if I use Server-Side Rendering (SSR) for the front-end, do I lose the SPA concept? In other words, would the application still be a true SPA, or does server-side rendering turn it into an MPA or a hybrid app?

An "SPA" is a Single Page Application.

There are no rules which say that using Server Side Rendering technology negates Web page being a Single Page Application.

You can publish your Single Page Application using and including any technologies you decide to.

My suspicion is Next.js is overkill for an SPA, given the capabilities of Web API in modern browsers, and HTTP/3. That is, I would first write out why Next.js, and/or any other framework is necessary to achieve the mission statement of the SPA.

Just make sure it's really a Single Page Application...

However, do whatever you want is the whole of the law.

The front-end must be a private SPA, accessible only to authenticated users.

That part is difficult to achieve, and verify that's what happens outside of your control.

Nowadays there is a such thing as an Isolated Web App. It's a Signed Web Bundle that a user launches from their desktop or browser, and has a permissions and feature policy, and CORS/CORP/COOP/CSP baked-in model designed for developers to deploy their application in a cross-origin isolated way loaded in the browser; encrypted in a single bundle. Might be some technology and capability you find interesting for your "must be a private SPA" requirement https://github.com/wicg/isolated-web-apps.