Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

161–170 of 516 posts

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

#161
post #153

I think this article is unfair to SPAs. SPAs are a lot more effort, but they are better. For a long time they have been the only way to "make it feel like an app." (I think the author says "make it feel like an app" because they know we all resent app fatigue, all the apps we have to download that should just be web sites, but I think we also all know that when something really is an application, it's rare for a "web…

“But they are better”

By what measure?

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

#162

Earlier quoted context omitted.

Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.

It really depends. There’s a lot of SPAs which are practically unusable on a bad connection simply because it’s a challenge to even get the whole thing loaded in the first place. There’s been several occasions where I’ve had poor cell connectivity and a huge chunk of the web was effectively off limits due to this. So in addition to aggressive caching, I’d say keeping the app’s file size down is also pretty important…

All three comments to this thread have missed the point that OP said installable SPA, not website SPA. This means the primary bundle is downloaded offline and only API network requests are necessary.

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

#163
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…

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.

HTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.

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

#164

I don't know what universe this SEO-consultant author lives in. The author gives Next & Nuxt as an example of the kind of frameworks going against his prescription, but that is so wrong. 1. Next won the war in the west, big time. Very very big time. Whenever people talk about new React apps they inadvertently mean Next. On the Vue side Nuxt is the default winner, and Nuxt is just the Next of Vue. That means that by d…

[deleted]

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

#165
post #163

Earlier quoted context omitted.

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.

HTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.

I meant for the SPA-like experience.

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

#166
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…

In a similar use, a few of my hobby projects are hosted on static web servers. So instead of rendering out everything into individual pages, which would've been tens of thousands of pages, I have a JSON file that gets rendered by the client in a SPA. I have even used Github Pages for this

I'm playing around with a newer version that uses a sqlite database instead. Sqlite officially has wasm builds, and the database file is already built to be separated into pages. With HTTP Range Requests, I can grab only the pages I need to fulfill any queries.

Sqlite full text search even works! Though I'm hesitant to call that a success because you do end up grabbing the entire FTS table for shorter searches. Might be better to download the entire database and build the FTS table locally.

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

#167

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 c…

> What counts as "SPA" and what's an "MPA"?

By how many times the Window's load event fire for your app.

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

#168

Earlier quoted context omitted.

Side note, sick of jQuery being always associated with spaghetti in the tech lexicon. Any Turing-complete system is spaghetti in the hands of bad programmers. And simple & clear in the hands of good ones who know how to design.

Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, tha…

> If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture.

My bet is that everyone here both agrees with you and is able to replace "jQuery" with "HTML", "CSS", and "JavaScript" to reach similar conclusions about the cultures of each. The problem is bad programmers, not the tech.

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

#169

Everyone is completely missing the point of this article, which I find amusing and terrifying in equal measure. He is _not_ talking about a SaaS dashboard SPA. He's talking about marketing sites and other content heavy stuff like blogs, landing pages, etc. It mentions this in many places if you go past the headline. He is completely correct. SPAs should not be used for marketing sites full stop. Perhaps there are som…

You of course don’t need 10MB of JS for a React blog or 120MB for an e-commerce site.

You’re not mad at SPAs, you’re mad at bad developers.

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

#170
post #145

Earlier quoted context omitted.

> every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. I'd argue then you don't have an SPA. However I don't see how you could have a application like Figma or Discord and say "ordinary HTML is faster" (or even possible).

You mean a chat cliënt? That seems a good worse case scenario. If you limit history to the most recent message (and have an link to the archive at the top) you could simply reload the entire page on some interval that declines with message frequency (and when you submit the form) Since the html document is pretty much empty the reload happens so fast you won't see the flashing. With transitions it would be perfectly…

> You mean a chat cliënt?

Calling Discord "a chat cliënt [sic]" is barely one step removed from "I could build that in a weekend". So go ahead. Wait, what is stopping you?

Post reply on HN