There's still value in web applications what can perform most of their operations client-side, when feasible. Lots of websites seemingly operate under the assumption of "If the client manages to connect to the server once, then surely it can maintain a stable, low-latency connection in perpetuity." This renders those websites unusable on flaky connections or with very high latency. Of course, plenty of SPAs are guilty of using 15 million unnecessary round-trips, but I worry that the current SSR-everywhere push will worsen this effect.
It's time for modern CSS to kill the SPA
11–20 of 516 posts
Re: It's time for modern CSS to kill the SPA
#12Rolling eyes Another person mixing up web apps with web sites. We do need frameworks for web apps. Yes people were wrongly making websites using frameworks. But I am busy building web apps and without frameworks it is not feasible to build one.
Exactly. I remember the times when webmail clients were SSR applications. Roundcube and Gmail were game changers. Webmail finally felt smooth and usable.
Web shops are somewhere in the middle, they need a little bit of interactivity for the cart, especially if the user opens multiple tabs.
But static websites should never be SPAs.
Re: It's time for modern CSS to kill the SPA
#13Rolling eyes Another person mixing up web apps with web sites. We do need frameworks for web apps. Yes people were wrongly making websites using frameworks. But I am busy building web apps and without frameworks it is not feasible to build one.
You really don’t need the frameworks for web apps either.
Re: It's time for modern CSS to kill the SPA
#14SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.
Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.
But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead.
Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.
Re: It's time for modern CSS to kill the SPA
#15The View Transitions API is beautiful and I can't wait for it to become widely available.
I've soured on SPAs in the past few years. So much more can be done with standards than people realize. SPAs were best for specific use cases but we made them the default for everything. Marketing pages are built in React! Basic pages with marketing copy have a build step and require hundreds of megabytes of dependencies.
Like the author I've transitioned to a mantra of "let the web be the web."
But we have a whole generation of developers and designers that have come of age with SPA and mobile-like ux as standard. Getting everyone back to basics and understanding hypermedia, markup languages and cascading styles is a big ask.
Re: It's time for modern CSS to kill the SPA
#16[deleted]
Re: It's time for modern CSS to kill the SPA
#17This reads more like "ditch Next.js" for traditional SSR. A good SPA has a lot of benefits. Because it can be interactive like a native app. It can only use those benefits, if it is interactive to some extent (like gmail or google docs). Smooth navigation is a very bad reason for picking a SPA.
What do you mean by 'interactive like a native app'? The article is focusing on two main parts of making things feel like an app: page view transitions and speed/preloading. To me, those seem like a big part of what makes a site/app feel interactive. And letting the browser do the work and having real URLs has other huge benefits I appreciate. But agree that for things like GMail, etc, a SPA approach definitely makes…
Imagine Gmail, ChatGPT, Slack, and so on as server side rendered websites, but with smooth transitions. This wouldn't work at all.
Let's take slack as an example. We had those chat websites 20 years ago. The thread was in it's own frame and got periodically reloaded. It's just bad UX.
Re: It's time for modern CSS to kill the SPA
#18SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much. Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category. A common use case is when you come to a sho…
HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build a lot of it on the server side, and add some dumb interactivity on the client (show/hide, collapse/expand, effects). There is still a place for SPA though.
Re: It's time for modern CSS to kill the SPA
#19This argument is tired and ignorant. Try building linear.app without a SPA framework. The idea that "Native CSS transitions have quietly killed the strongest argument for client-side routing," is dubious at best.
Re: It's time for modern CSS to kill the SPA
#20This article would benefit from an example page to show how these "feel".
Here are a series of demos. They work in Chrome or Safari.
https://view-transitions.chrome.dev/
Here's an older, more designed demo that only works in Chrome.