It's time for modern CSS to kill the SPA • Hacker News Board

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

#111

Post by andrewaylett » Fri, Jul 25, 2025, 11:21 PM UTC

What counts as "SPA" and what's an "MPA"? I've got a NextJS site (my personal website, you can probably find it given you know my last name and that I'm in the UK) that renders pretty much everything server-side. Technically it's still an SPA because if you turn on Javascript it'll load RSC and do client-side navigation.

If you turn off Javascript? Pages with client-only components (like the 100% client-rendered QR code generator) will show their fallback, everything else will load and render perfectly -- if a little less quickly -- than if you let Next do its thing. It's all rendered into the HTML, and it's actually more effort to not render components on the server. Progressive enhancement for the win!

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

#112

Post by crazygringo » Fri, Jul 25, 2025, 11:22 PM UTC

zeroq wrote: post #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 sho…

Generally speaking, companies don't want you to download their entire catalog. They don't want competitors to be able to analyze it easily like that.

And if a store is selling books, it might have hundreds of thousands of them. No, it's not a good experience to transfer all that to the client, with all the bandwidth and memory usage that entails.

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

#113

Post by etchalon » Fri, Jul 25, 2025, 11:24 PM UTC

If you think SPA's became the dominated architecture because of page-to-page transitions, I'm not sure how to have a productive conversation with you.

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

#114

Post by wldcordeiro » Fri, Jul 25, 2025, 11:24 PM UTC

mattbrewsbytes wrote: post #90

codingdave wrote: post #14

SPAs 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 absolu…

If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache. HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.

Lots of SPAs now are code-split too for what it's worth so you shouldn't really have large bundles to download if you're splitting things well.

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

#115

Post by cweagans » Fri, Jul 25, 2025, 11:26 PM UTC

andix wrote: post #42

cweagans wrote: post #36

Earlier quoted context omitted.

What if I told you that you didn't need jQuery either.

Using the DOM APIs directly? Please do that. Have fun!

What if I told you that you didn’t even really need javascript for most things - even more involved web apps. HTML and CSS is plenty for many things.

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

#116

Post by dsego » Fri, Jul 25, 2025, 11:27 PM UTC

buffalobuffalo wrote: post #26

codingdave wrote: post #14

SPAs 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 absolu…

I don't know if a bunch of sloppy jQuery modules were ever really a viable option for an SPA. People tried to do it, sure, but I'd say the SPA era really started with backbone.js

I mostly remember doing $(document).ready blocks in php templates :)

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

#117

Post by onehair » Fri, Jul 25, 2025, 11:32 PM UTC

Props for teaching me about View Transition API.

Absolute disagree with the way you're arguing though.

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

#118

Post by dsego » Fri, Jul 25, 2025, 11:32 PM UTC

jiggawatts wrote: post #78

codingdave wrote: post #14

SPAs 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 absolu…

The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else. Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”. My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice.…

And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.

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

#119

Post by thaumasiotes » Fri, Jul 25, 2025, 11:32 PM UTC

nine_k wrote: post #45

da_chicken wrote: post #25

Earlier quoted context omitted.

I don't know, I think the most painful aspect of having to do a full reload is how I efficient the site is. The actual data is a few KB, but the page itself has to download 100 MB and the web browser is burning through a GB of RAM. Like I don't find Hacker News to be egregious to navigate, and nearly every nav is a reload. It runs fine on my 2008 laptop with 4 GB of RAM. But I go to DoorDash on the same device, and i…

An SPA can be lean and fast. React is the prevailing Web framework today? Preact is like 5 KiB of code. What makes SPAs unwieldy is not the technology but the lack of desire to optimize. It loads fine on yesteryear's Macbook Air? Enough, push it. I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of…

> I very well remember heavy, slow-loading websites of, say, year 2000, without any SPA stuff, even though lightweight, quick-loading pages existed even then, in the epoch of dial-up internet.

Sure, lightweight, quick-loading pages existed, but sometimes you want to see a picture.

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

#120

Post by keeganpoppen » Fri, Jul 25, 2025, 11:33 PM UTC

kassner wrote: post #79

chaps wrote: post #29

Earlier quoted context omitted.

Is this true? When I think of old SPAs I think of java apps running in a browser. Those are definitely older than jQuery. (I love this silly site for downvoting this question.)

ExtJS came about in the late 00s, and it was possible to build SPAs with it, overlay/draggable windows, and had powerful grid/form components.

oh man now THAT is a real blast from the past. oh man, pretty classic "where did all the time go?"... "oh yeah i forgot that i spent like 100s of hours battling with sencha back in the day". selective memory isn't always a bad thing, i guess.