Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

1–10 of 516 posts

Re: It's time for modern CSS to kill the SPA

#2
This 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.

Re: It's time for modern CSS to kill the SPA

#5
Rolling 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.

Re: It's time for modern CSS to kill the SPA

#8
post #2

This 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 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

#9
I completely agree.

My 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

#10
SPA 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 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.

Post reply on HN