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

131–140 of 516 posts

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

#131

Post by aryonoco »

Cthulhu_ wrote: post #70
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…

> 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; bi…

Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns.

Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt new Angular patterns.

Still, I believe Angular is a really great platform for building B2B or enterprise apps. It’s testing and forms handling is far ahead of every other SPA, and it actually fees like a cohesive framework where people have spent time designing things the right way; something I absolutely cannot say about react frameworks such as Next.js or Remix.

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

#132

Post by throw-the-towel »

TimTheTinker wrote: post #27
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…

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.

This is not true. In practice SPAs break completely when some network request fails which happens a lot on bad connections.

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

#134

Post by aryonoco »

Cthulhu_ wrote: post #70
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…

> 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; bi…

PS and I forgot to mention, new Angular patterns such as Signals and standalone components great cut down on the boilerplate and the verbosity. It’s not (and will never be) something like SolidJS, but each new version is clearly moving away from the heavy OO-based and multi layered patterns.

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

#135

Post by nine_k »

thaumasiotes wrote: post #119
nine_k wrote: post #45

Earlier quoted context omitted.

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.

Google appeared in 1998. It was very noticeable how fast it loaded compared to competitors like AltaVista and Yahoo. None of them featured large photos.

This was visible not only on a 33600 phone connection at home, but also on a megabit connection at work, because, shockingly, how fast your backend is also plays a major role.

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

#136

Post by yawaramin »

paulryanrogers wrote: post #127
mattbrewsbytes wrote: post #90

Earlier quoted context omitted.

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.

Is this true everywhere? Isn't much of the world still on slow mobile networks?

Being on a slow mobile network and having to reload changing bundles multiple times a day to use SPAs would be an even worse UX.

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

#137

Post by wild_egg »

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…

> in exchange for having really small network requests after the load.

I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire.

Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well.

Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.

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

#139

Post by sfn42 »

LegionMammal978 wrote: post #11

There's still value in web applications what can perform most of their operations client-side, when feasible. Lots of websites seemingly operate under the assumption of "If the client manages to connect to the server once, then surely it can maintain a stable, low-latency connection in perpetuity." This renders those websites unusable on flaky connections or with very high latency. Of course, plenty of SPAs are guilt…

This works for some websites, not all. And often it results in significant loading times, because you're loading tons of unnecessary data. In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fast if you do it right. Since you're only sending minimal amounts of data everything is fast. The server can handle lots of requests and clients don't need a powerful connection to have a good experience.

Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server. If you make the backend slow then it'll be slow. If you make the request really large then the bad connection will struggle.

It's also worth mentioning that I would much rather deliver a good service to most users than make everyone's experience worse just for the sake of allowing someone to load the page and continue using it offline. Most websites don't make much sense to use offline anyway. You need to send some requests, best approach is simply to make them fast and small.

Post reply on HN