Why do we walk away from Single Page Applications?

The trends to and from SPA are driven by improvements in "edge" service to support dynamic content:

In the old days, we built dynamic web content with "AJAX". There was a lot of latency to for a request to reach your application server. It was also kind of hard to make the servers respond with low latency.

So we added more client-side scripting. We had things like script.aculo.us, and settled into jQuery. This improved the responsiveness of some aspects, but split the user's front-end experience across different systems, written in different languages, possibly developed by different people.

So the SPA unified things again. It maximized the part of the application delivered by the low-latency CDN. Only the essential dynamic data was transferred from the higher-latency back-end server. It fixed the cohesion of front-end development, by moving entirely into JavaScipt frameworks. So, done well, this improved responsiveness for the user of dynamic web content. On the other hand, maximizing the SPA resulted in a new problem: users get slow or inconsistent performance because of downloading a big JavaScript application. So this new kind of load time turns out to be pretty hard to optimize.

Now in 2023, it's easier to build low-latency back-end servers. We have various options of "edge compute". It's not too hard to put a copy of your application server in each region around the world. So it makes sense to run the application in the server again, not that it's distributed. Moreover, our web development frameworks are helping to keep the web application design cohesive.

So moving to SPA and now moving away from SPA are driven by the desire to have a low-latency experience for our users. Changes in the available infrastructure have changed the optimal balance of server-side and client-side execution of the application. And improvements in our development frameworks makes it easier to take advantage of the infrastructure improvements.

You don't need to do anything. If you're rewriting based on trends and not need, you're just following fashion. Does your app work? Keep it as is.

I find the combination of a component framework such as React with a fully fledged backend such as Laravel or Rails with Inertia.js is perfect. The best of both worlds.

All this server side components is just over engineering no one needs, and even if you think you need it the complexity and vendor lock in introduced is not a trade off worth to do in my opinion.

Why would you need to rebuild the Backend? A SPA usually consumes data from services, being it HTTP/JSON, gRPC or whatnot. You server-side components can consume the very same services with no changes in the backend.

SSR is almost always slower than SPAs. It's forcing a waterfall on first page dispaly (you can't stream HTML of something that hasn't been fetched from the database yet), and generally SPAs fail mainly at SEO. If you're not e-commerce, you probably just don't need it.

Honestly? I believe that the new hype of Server Side Rendering (SSR) frameworks is only a matter of vendor lock-in: when you have SSR, you *NEED* edge rendering, which only a few vendors can provide today.

Single Page Applications (SPA) are totally fine. My blog is an SPA (https://kerkour.com) and has no problem being indexed by the major search engines.

It's actually way faster than most webapps using new shiny new SSR frameworks as I can cache with precision the different chunks/assets.

Finally, everything is served from a server than barely uses more than 50 MB of RAM even under high load. Last time I looked, Next apps needed around 500MB-1GB of RAM to serve only a few visitors.

There's tradeoffs with anything. Sending HTML over the wire has benefits you're dismissing like faster response times since responses are cacheable. (The benefit can easily exceed some microseconds, especially if we're measuring time-till-the-user-can-actually-do-something.)

SPAs also have tons of benefits. Local state is awesome for instant reactivity once the page is loaded. But you also introduced an API that you now need to maintain, that 9/10 times, will only ever be used on this SPA and no where else.

It's just acronyms, pick whatever works for you. There doesn't HAVE to be one "best practice" that covers all use cases.

Hype.

Only apply for small use cases yet frameworks (especially next.js) want to sell you stuff.

I read a hype piece about “multi-page applications” and thought “so we’re back to making websites.”

SPAs seem like a good choice when the app should be able to preserve full functionality when offline.