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

291–300 of 516 posts

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

#291

Post by np1810 »

gabesullice wrote: post #250
np1810 wrote: post #225

On one hand, SPAs took off and became massively popular. On the other, I’m still curious why PWAs—especially the kind with service-worker-powered offline access—never really did. I don't like SPAs only if I find them bloated and with a messed up browser history that back button moves you out of the website. Imagine an e-commerce site that lets you review your order history and product pages offline (even if a bit out…

Offline is good for things like your ball sort game or a calculator. But the developers of that sort of thing want to make money, so they sell apps in the app store. Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess. In other words, offline isn't PWAs kill…

> PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.

Agreed, I wish we lived in world where PWAs had atleast an equal share compared to mobile apps. Apps winning, mostly have been a suicide for privacy.

Coincidentally, there's another HN story with even more relevance to our discussion. [1]

[1]: https://news.ycombinator.com/item?id=44689059

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

#293

Post by SenHeng »

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…

> It's much better ux when a user downloads the whole catalogue and then apply filters on the client without having to touch the server until he wants to get to the checkout.

This is what we[0] do too. We have a single JSON with a thousand over BOMs that's loaded directly into the browser. Previously we loaded the inventory data via an API as is usually expected. The fact that there's even an API meant requiring progress and loading bars, API unavailability scenarios, etc.

Having it all as a single preloaded JSON meant that all of the above goes away. Response is instantaneous.

[0]: https://chubic.com

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

#294

Post by pyman »

40four wrote: post #210

This article is getting a lot of pushback from the SPA champions, deservedly so, but it makes some good points to. I can’t be the only one, but I myself am getting very tired of the amount of websites where I have to sit and look at a skeleton loading for way too many seconds, then the data loads and it looks nothing like the skeleton. There is an over abundance of really crappy SPAs out there. Sorry not sorry

I thought about your comment, and IMO the reason some (or most) SPAs are badly built comes down to the inexperience of developers and hiring managers. They don't know much about performance, they don't measure it, they don't handle errors properly, they ignore edge cases, and some are learning as they go.

Bottom line: they build the SPA, but leave behind a terrible UX and tech debt the size of Mount Everest.

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

#296

Post by curtisblaine »

Not only SPAs are here to stay, but they're eating up native app on the desktop (with Electron et al., it's much easier to hire TS devs and write your app once rather than have different native codebases for Windows, Macos and Linux).

Now, I understand the argument that simple article-based websites shouldn't necessarily be SPAs. Page transitions are perfectly doable in pure HTML and CSS. But if you have less then trivial local state and complex + specific components, forcing the MPA pattern will only complicate your codebase.

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

#297

Post by maccard »

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?

I live in the middle of a major UK city, which is one of the most visited tourist destinations in the UK (if not the world). There are massive gaps of mobile coverage in the city - 5G is spotty at best, and it regularly falls back to much older protocols in the city. There are dead zones where you can literally walk 6 ft and drop to 0 coverage, and walk another 6ft and be on full blown 5G. Apps and sites like uber, twitter, Reddit, instagram all handle these awfully.

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

#298

Post by al_borland »

Quarrel wrote: post #281
danielscrubs wrote: post #265

Earlier quoted context omitted.

Google Maps cant even preserve state in their iOS app. They are either the worst developers in the world or it is not simple. I don’t rule any of the two possibilities out. Some things you get for free with the correct architecture. For whatever reason, SPA does not have a great track record with their users.

> They are either the worst developers in the world or it is not simple. Or they have a good reason to not do it (in some PMs mind). At a guess, resetting the view, and displaying the nearest Domino's Pizza sponsored highlight pin on the map, could be one of them.

My biggest gripe with Google Maps is when I pan to a specific area, hundreds, or even thousands of miles from my current location, then search for something like “restaurants” and it pans me back home and searches there, so I then have to go find my distant location again and click the search here button.

If this is an intentional choice, all in an effort to show me more local ads… ugh. I really hope this isn’t the case.

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

#299

Post by wlll »

It's time for sending HTML rendered on server with CSS, and JS for enhancement only to kill the SPA.

I'm not talking about this from a technical standpoint, though there are many reasons that in most cases this is the best technological fit.

I'm talking about this from the position of "what I want to use". I'm sick of loading and navigting overly JS heavy, overly styled, fragile "apps". When I encounter a "proper" website that loads fast, and I can understand easily it's like a breath of fresh air.

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

#300

Post by maccard »

8n4vidtmkvmk wrote: post #228
wild_egg wrote: post #137

Earlier quoted context omitted.

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

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

HTML templates are still text, text compressed well. As with all these discussions “it depends, profile it” is the only answer. People blindly assuming that X is better is why things are slow and shitty in the first place
Post reply on HN