Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

351–360 of 516 posts

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

#351
post #340

Earlier quoted context omitted.

> It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. Why would the browser have to reload the code (JS files) on every page transition, with proper caching headers?

Click on a link on Amazon and take notice of all the kb of data in the head of every document that doesn't get cached.

But you were talking about code, not data, hence my question. Also, Amazon doesn’t need to be that way (and wasn’t twenty years ago, the motivating period we are talking about).

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

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

This wouldn't work for 90% of apps out there. While I would love that approach, it has so many problems that in practice it never worked out for me. First problem is that data change. Either you edit it, or you need updates from server applied to your copy. This is quite complex (although there are some solutions, I had little luck in making this work reliably). Second - you don't want to share the whole catalog in one request. Third - in most cases there is a lot of data. It's not uncommon to have tens of thousands of items and for each you likely need some kilobytes. Four - you are downloading the whole catalog even for deep links which might not care about all but a tiny fraction of that data.

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

#353
post #285

Earlier quoted context omitted.

to be fair to both points: he has a really warped view that SPAs are somehow purely about routing. he does correctly point out that a lot of sites could and should be treated as sites not apps.

I agree with you. The author's point is that browsers have finally understood why some traditional sites were created as SPAs, which involves recreating some of the functionality browsers already offer today. But that doesn’t mean all SPAs should turn into MPAs now. IMO it will be hard for some traditional sites to adapt to the new browser capabilities, since we've built an entire ecosystem around SPAs. The author's…

Even for basic sites, I tend to reach for an SPA because I never know when I'll be adding dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data.

It's usually inevitable, so it's easier to scaffold a Vite template and get cracking without any additional setup. The time-to-deploy is fast using something like Netlify or Vercel, and then I have the peace of mind knowing I can add additional routes or features in a consistent, predictable way that fits the framework's patterns.

I'd hate to develop an MPA and realize after the fact that now I need complex, shared data across routes and for the UX to be less disrupted by page loads. Once you've dug that hole, you either have to live with it, or face a painful rewrite later.

The exception I often see is targeting mobile devices in low-bandwidth areas where larger application bundles take longer to load, but I have to wonder how often this is the target audience. I live in a place where mobile data speeds are horrible, and access to WiFi is abundant, but even so, I rarely have a situation where I *need* to load up a non-critical site on the go — and having apps pre-installed doesn't really help either when the data they're requesting is barely trickling in on mobile.

So this oft-used exception doesn't really make sense to me unless I learned why this is so critical for some people.

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

#354
it makes more sense than ever to deploy a semantically correct page with clearly distinguished templatnig, styling, animation logic and most importantly - data semantics. so that the robots and LLMs can slurp it without clicking too much. all the styling can follow in a very standards-compliant manner.

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

#355

Earlier quoted context omitted.

You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll…

> You miss the whole point and the author is correct about this: your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why. > Modern CSS is powerful, and HTML is the way to deliver web content. Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the…

Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled.

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

#356

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…

How did next win the React framework war? Is it not few years already that see exodus from next to remix/react router, and more recently to tanstack start etc. because of unnecessary complexity, difficulty to run next on anything but vercel, misguided API changes etc.?

You mentioning facebook docs pointing to next, when they explicitly mention remix and other is quite misleading.

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

#357

Earlier quoted context omitted.

What particular issues have you experienced?

It’s extremely hard to use reliably. Anyone enthusing about this API hasn’t done much with it.

What exactly hurt the reliability? Early on, I often ran into false starts because I did not pay enough attention to proper render blocking.

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

#358

Earlier quoted context omitted.

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never rea…

You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll…

> Every web framework is _literally_ a hack to make the web something it isn't.

Not this old grumpy person take again.

Yes, the web is developing beyond delivering html content.

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

#359

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…

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never rea…

I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective:

I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.

Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views.

I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.

Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.

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

#360

Earlier quoted context omitted.

You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll…

Laravel is fine. It's not amazing . Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspo…

[deleted]
Post reply on HN