Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

Post reply on HN
Print view View original

231–240 of 516 posts

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

#231

Post by gethly »

I strongly disagree with this. SPA has its place and a very important one. It is not just about replacing JS animations with CSS animations. Of course it depends on the use case - SPA makes little sense in many cases and a lot of sense in few. But it still has it's stable place.

From my own point of view and experience, SPA makes the most sense when you do not want to bundle backend and frontend together in your server code. Having a separate FE and BE with clearly set API(json) is very important in many many many cases and it allows you to use the same BE for different FE, like desktop website, mobile website, desktop client(electron), mobile application... trying to do this on the server would be hell. Also worth mentioning is that if you want to make changes in your FE, you have to bring down you BE in order to deploy them, whereas if you have BE and FE separated, you can deploy the FE without any downtime.

There is a lot more that could be said but the main point is that moving data rendering into FE and letting BE just serve raw data is the way to go in many situations.

We have been moving computation between FE and BE for decades now, but I think the tech is now sufficient to not force us to pick one over the other but chose what works best.

Personally, I think that rendering the UI on BE is archaic and should be handled on the client via some bundled thin client code, ala SPA. So I will always prefer client-rendering over server-rendering, no matter the setup.

PS: You might be interested in https://data-star.dev/ which came out of dissatistfaction with HTMX and I think will be the way to go about bridging FE and BE in the future.

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

#233

Post by ozim »

zahlman wrote: post #31
andix wrote: post #22

Earlier quoted context omitted.

I guess you never worked on a complicated web app that was 100% jQuery, because web frameworks were not a thing yet.

I did, around 15 years ago. It was honestly not that bad.

How many people did you have on your team? What was employee turn over on the project? How long was the development?

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

#234

Post by donatj »

nfw2 wrote: post #180
adamtaylor_13 wrote: post #161

Earlier quoted context omitted.

“But they are better” By what measure?

Performance, developer experience, user experience

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off.

Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.

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

#235

Post by Zanfa »

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

Does a real-world example of bandwidth saving even exist for SPAs? It’s always the other way around where what could’ve been a single page load, ends up being 6 separate asynchronous calls to different APIs to fetch random bits and pieces while the user stares at spinners.

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

#236

Post by luis_cho »

danielscrubs wrote: post #220
cheema33 wrote: post #185

Earlier quoted context omitted.

> ...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct. Agreed. The article was a frustrating read. The author is an SEO consultant. SEO consultants likely have a heavy focus on marketing websites. Actual apps and not marketing websites do benefit significantly from SPA. Imagine building Google Maps without SPA. You can animate page transitions all you…

I 100% would like to see an MPA Google Maps. Being able to come back to a webpage with previous directions? I think it would be glorious.

The author states that MPA are not a solution for everything. Sure google maps don’t fit the MPA model but I’ve seen a lot of projects that would be much better using current browser features instead of react.

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

#237

Post by Zanfa »

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…

Please no. Whenever I see an online store as a SPA catalogue I shudder, because it usually breaks after browsing a bit in a weird state. And it resets to somewhere random should you hit back, refresh or try to send a link to somebody.

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

#238

Post by luis_cho »

wolpoli wrote: post #192
TimTheTinker wrote: post #27

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.

Honest question: Where are the places with low-bandwidth internet? Are we talking about cruise ships and satellites internet use cases?

There is this post about a experiment on google where they reduced the page weight and the traffic went up instead of down. That was because it open the site to countries with low internet bandwidth https://blog.chriszacharias.com/page-weight-matters

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

#239

Post by frollogaston »

Tokumei-no-hito wrote: post #211
frollogaston wrote: post #183

Earlier quoted context omitted.

Kinda is a war unless you're working solo, cause you're gonna get forced to use something or another. When I tried a few solo web projects instead of just being a backend guy, I picked up React on my own because it was the only thing that makes sense. The page does what the code says. And that was after trying other things. Now I gotta occasionally use Angular, and it's boilerplate hell. Adding one button involves ed…

in the world of frameworks it's obvious that html in your JS > JS in your html. angular is a mess. it's the java of web frameworks. if you want up be enterprise(tm) go for it. I’m convinced it's only a thing because it gives people job security since nobody else chooses to touch it.

There was also the actual Java of web frameworks, GWT

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

#240

Post by jaredklewis »

cosmic_cheese wrote: post #62
TimTheTinker wrote: post #27

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…

I work on an SPA with hundreds of screens. We package it using off the shelf tooling with barely any configuration. All of the code and styling is still far under a megabyte gzipped.

So unless it is an all text app, the size of the code bundle is probably going to be quickly dwarfed by the size of media like images, animated images, or videos.

If a site has an SPA with a, say, 3mb code bundle, I think in most cases, that’s not an architecture issue. It’s probably an issue of poor engineering and switching to a MPA is not suddenly going to make those engineers competent.

Post reply on HN