It's time for modern CSS to kill the SPA
jonoalderson.com
It's time for modern CSS to kill the SPA
1–10 of 516 posts
Re: It's time for modern CSS to kill the SPA
#2A 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.
Re: It's time for modern CSS to kill the SPA
#3Re: It's time for modern CSS to kill the SPA
#4You can pay some upfront cost and have wildly more performant apps.
Re: It's time for modern CSS to kill the SPA
#5Another 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.
Re: It's time for modern CSS to kill the SPA
#6Re: It's time for modern CSS to kill the SPA
#7Re: It's time for modern CSS to kill the SPA
#8This 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.
But agree that for things like GMail, etc, a SPA approach definitely makes sense. I just think most SPA sites I come across aren't in that category.
Re: It's time for modern CSS to kill the SPA
#9My SPA navigation solution is just simple CSS toggle of display none/block and then force it on page load if there is a matching URL fragment. Total JavaScript to make this SPA navigation is about 20 or so lines of JS. Everything else is CSS and WebSockets. The state management is almost as simple.
Re: It's time for modern CSS to kill the SPA
#10Let 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 shop, click on "books" (request), then on "fantasy" subsection (another request), realize the book you're looking for is actually a "sci-fi", so you go back (request, hopefully cached) and go to "sci-fi" (another request).
It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.
But it's a lot of data - you may say - maybe on Amazon, but you can efficiently pack sections of most shops in data that will enable that pattern in less kilobytes that takes one product photo.
I've been building web apps like that since ca. 2005 and I still can't understand why it's not more common on the web.