The myth that you can’t build interactive web apps except as single page app

I am no frontend-guy, so I don't understand why in the age of node.js web-servers this ditchonomy exists between server-side and client side (SPA). Can't you initialise/pre-render most of your your stuff on the server, serialise it and push it through the client, which then acts as an SPA already initialised and then updates itself on its own. After all, both are JS? Why is the decision not more flexible where to run code, depending on latency, compute intensity etc. Maybe someone can enlighten me, as this is often left out, probably because it is obvious to someone working with these technologies.

I'm answering your initial question directly, but there is more going on that may be more informative.

This is a distinction between computation that is performed on a server, using arbitrary tools, and computation run on a user's machine locally. The former is much more flexible, but comes at a cost of latency; all user input and output must be serialized, and transmitted a long distance. Front end code can result in much lower latency to the user due to ommitting this transmission.

It makes sense to apply a suitable mix of these two tools that varies based on an application's details. For example, an immediate UI response that can be performed using only information already present on the client makes sense to be handled exclusively there, as computation time is minimal compared to transmission and serializtion.

I believe that JS being able to be used on a server is not relevant to the core distinction.

You can! The terms to search for are "isomorphic web apps" and "hydration". It's definitely not a panacea though.

https://react.dev/reference/react-dom/client/hydrateRoot

You don’t need a SPA or to pre render anything. The reasons these things occur is because most of the people doing this work cannot program and cannot measure things.

This is what frameworks like SvelteKit and NextJS do

Hydration is not needed tho, frameworks like Qwik allow isomorphic apps without hydration.

One thing might be that you can build an SPA into a mobile app, which maybe would have a harder time passing review with app stores if half the code is running somewhere else? Having said that, of course backends do already exist, but I wonder if it might be viewed slightly differently.

On the server, applications are generally super close to their backend dependencies, so multiple round trips to data stores, caches and whatnot are no problem. On the client, this would be deadly.

So it’s not just easy to take code that runs on the server and run it on the client. Anytime the client needs to do more than one round trip, it would have been faster to render the data completely on the server, html included.

Additionally, with SPA’s there’s a lot of nuance around back/forward handling, page transitions, etc. that make a page based application awkward to turn into a purely client side one.

why? what are the main drawbacks? I imagine the complexity, but can you go a little bit into the details for someone with only little frontend experience

> t would have been faster to render the data completely on the server, html included.

OData batch, GraphQL, and similar technologies exist to reinvent this wheel:

"What if instead of a hundred tiny calls we made one high-level request that returned a composite formatted response that includes everything the client needs to show the next state."

Also known has... server-side rendered HTML like we did since the 1990s.

This is what Next.js does.

> then acts as an SPA already initialised and then updates itself on its own

A lot of the trouble is how that data is "initialized". State management and state ownership are old complications in every client/server application back to the dawn of time. In the old "Progressive Enhancement" days all of the state was owned by the HTML DOM and JS would pick that up and reflect that. In a lot of the modern SPAs the state is owned by the JS code and the DOM updated to reflect it. The DOM never has a full picture of the "state". So state has to be passed in some other channel (often referred to as "hydration" by data/state as water analogy).

Also, in most of the SPA frameworks, state management is deeply entangled with component management and the internals of how everything is built. It may not be deterministic that the server running the same code gets the same data, produces the same results. It may not be easily statically analyzable which components in the system have which data, which outputs given which data are repeatable enough to ship across the wire.

(I just released a low level server-side rendering tool for Butterfloat, and one of the things that kept it easy to build was that Butterfloat was built with an architecture that more clearly separates static DOM from dynamic updating state bindings.)

Though, as most apps are built, only the code run on the server can be trusted, and only the response processing performed on the server can be trusted.