[dead]
It's time for modern CSS to kill the SPA
61–70 of 516 posts
Re: It's time for modern CSS to kill the SPA
#62SPAs 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…
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 to making it useful on poor connections. That’s frequently something that’s barely optimized at all, unfortunately.
Re: It's time for modern CSS to kill the SPA
#63I 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…
There was a war? News to me. Saying Next won is like saying React won. Nothing won, everyone just latched on to what they thought the crowd vetted. The blind can't lead each other. Most people that stuck to Angular or minimal or no-frameworks are truly wondering what the fuck are all these people talking about? . Even the Facebook docs point straight to Next Startups and SV jerk each other off by promoting each other…
> Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit.
No, this is FB ceding the battle. They absolutely didn't want this. They dropped CRA because social media celebrities were shitting on CRA. Dan Abramov had to do a complete 180 in a single day, after writing a long thoughtful essay in defense of CRA.
Re: It's time for modern CSS to kill the SPA
#64I once worked at a place where (for involved reasons not worth rehashing for this conversation) some of the backoffice, admin pages got rewritten in SPA fashion, after they had already been written in server-side fashion. It was an accidental experiment that showed me that the backend code did not decrease in size, whereas the frontend ballooned up to the same size as the backend (for fairly simple functionality even).
Now, this means you will need approximately twice as many developers. On the plus side, more work gets done on the client-side, so you probably need fewer servers for your billion users, and you may save in servers (and sysadmins) more than it costs you in developers to handle approximately twice as much code.
Except...99.9% of the shops using SPAs don't (and never will) have enough traffic for that tradeoff to make sense. The devs want (or at least wanted, back in the day) to go work at a company that did, so they wanted to use tools that would make sense if you're Facebook-sized. But, for the great majority of shops that made SPAs, there was no good reason to do so. This isn't Facebook's fault, but it is a reason why SPA's are annoying to so many people; they are almost always used in places that don't need them, and shouldn't be using them, in order to pad out a resume.
Re: It's time for modern CSS to kill the SPA
#65Re: It's time for modern CSS to kill the SPA
#66SPA 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…
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…
Gmail takes 3s to load. And HN is a website, not an app.
Re: It's time for modern CSS to kill the SPA
#67SPA 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…
You can do that with checkbox selectors. e.g. see [0]. Note that I don't really do frontend and I asked chatgpt to vibe code it, so this may not be the best way to do it.
[0] https://html-preview.github.io/?url=https://gist.githubuserc...
Re: It's time for modern CSS to kill the SPA
#68Any website that is an app is going to need SPA like features.
Especially if they have some kind of AI integration feature.
Re: It's time for modern CSS to kill the SPA
#69Earlier quoted context omitted.
There was a war? News to me. Saying Next won is like saying React won. Nothing won, everyone just latched on to what they thought the crowd vetted. The blind can't lead each other. Most people that stuck to Angular or minimal or no-frameworks are truly wondering what the fuck are all these people talking about? . Even the Facebook docs point straight to Next Startups and SV jerk each other off by promoting each other…
> Startups and SV jerk each other off by promoting each other (think affiliates). None of it means shit. No, this is FB ceding the battle. They absolutely didn't want this. They dropped CRA because social media celebrities were shitting on CRA. Dan Abramov had to do a complete 180 in a single day, after writing a long thoughtful essay in defense of CRA.
You are in your own little universe. Social media celebrities shitting on React? I don't even want to enter your world.
"Bro, you should see the celebrities shitting on React"
Like WHO!? What developer celebrity, what universe have I been missing out on?
Anyway, I do love me a good ol' fashioned "fuck SPAs, back to HTML" punching bag post on HN. It's always the same discussion over and over.
Re: It's time for modern CSS to kill the SPA
#70SPAs 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…
> and load up a giant pile of jQuery spaghetti
I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification.
Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; biggest ones was its modularization (which wasn't a thing in JS yet), dependency injection, and testability.
When we started out with an app in Backbone (to replace a Flex app because it wouldn't work on the ipad), I actually advocated against things like testing, thinking that the majority of functionality would be in the back-end. I was wrong, and the later AngularJS rebuild was a lot more intensive in front-end testing.
Of course, nowadays I'm repulsed by the verbosity, complexity and indirection of modern-day Angular code. or Java code for that matter.