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

461–470 of 516 posts

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

#461

Post by hasanhaja »

wredcoll wrote: post #443
vanviegen wrote: post #438

Earlier quoted context omitted.

I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?

The "Just" is doing a lot of heavy lifting there. Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a tag and each row in a tag and that would indeed be easy. But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or pa…

How does something like React help with any of the trickier UX problems you're describing?

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

#462

Post by andersmurphy »

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.

I think with brotli over SSE you can do just fine with 3G and bad networks without needing to be a SPA. Keeping almost all state on the sever make realtime collaborative apps much simpler than data sync you need with SPA. This demo has zero client side state and handles concurrent interactions over a billion data points [1].

- [1] https://checkboxes.andersmurphy.com

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

#463

Post by hasanhaja »

zero_shift wrote: post #275
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…

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…

Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)?

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

#464

Post by nfw2 »

epolanski wrote: post #289
nfw2 wrote: post #179

Earlier quoted context omitted.

Where is 1% coming from? None of the software jobs I've worked at or even interviewed to work could have functioned as a website

Can you link those? Because I mostly built backoffices, chats, forums, ecommerces, all things that would've worked better as websites.

Here are some of the things I've worked on: - payroll and other hr software - educational software - shared workspace for realtors and homebuyers

I'm not going to doxx myself by naming all the companies, but here is an example of a page that has too many features to work as a website. https://www.compass.com/listing/7310-estrella-de-mar-road-un...

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

#465

Post by layer8 »

chuckadams wrote: post #417
layer8 wrote: post #345

Earlier quoted context omitted.

Document-centric, form-driven websites aren’t traditionally called apps. The Wikipedia website isn’t an app. Web forums aren’t apps. “App” implies that essential parts of the interaction logic are driven by client-side code (JS, not HTML) that couldn’t similarly be implemented by HTML forms.

Sure Wikipedia is an app, long as you think of static websites as a subset of web apps. One might say that makes the term meaningless, I say it's a deliberately vague term because people don't want or need to get cornered by fine distinctions. Otherwise it's endless quibbling over whether things like search do or do not count toward a site being a "real" app.

Your definition of the term simply doesn’t match common usage.

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

#466

Post by threatofrain »

brulard wrote: post #458
threatofrain wrote: post #448

Earlier quoted context omitted.

https://npmtrends.com/next-vs-nuxt-vs-remix Also look at trajectory. Oh my, don't you think? When I choose things like Tanstack Start, I am very clear that this is beta software and an early bet. When I'm talking about winners in the ecosystem, I am not going to bring up Tanstack and most definitely not Remix. I don't want to confuse people into thinking they belong on the same table of discussion for ecosystem winne…

Your information are outdated. Let me correct your chart a little https://npmtrends.com/next-vs-nuxt-vs-react-router-vs-remix Remix no longer exists as it was all migrated to react-router. react-router v7 is what remix v3 should have been.

I think at some point there was more interest in framework as a startup, and there was indication that having a popular router (React Router) was a sufficient advantage in the race to at least try to win.

Then Shopify bought them up to maybe hedge against Hydrogen. Remix never went anywhere for Shopify, Shopify didn't buy React Router, only Remix. Now, as you say, Remix is being retired. My own Remix app was rewritten as I was tired of upgrading pains.

But what do you think of the argument that this is moreso Shopify folding their hand than Shopify realizing their bet via React Router?

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

#467

Post by threatofrain »

afavour wrote: post #92
threatofrain wrote: post #63

Earlier quoted context omitted.

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

Wars, battles, personalities on social media… I don’t want to sound too much like a grouchy old man but these frameworks are tools. Nothing more than that. I can’t understand why anyone would become emotionally invested in any of them. When starting a project the right move to examine what best fits your project, not which one was recently victorious in a war. I’ve grown to dislike React because I see it being abused…

You can ignore all the phrasings of wars or battles or winning and losing, and you can also ignore that social media has consequences.

We can agree that frameworks are just tools. And as tools we can coldly think about trends and other meta-facts, including questions on popularity. We don't need to think about popularity in terms of winning or losing either, just numbers that move around so we can use them as predictors of mindshare and career opportunities.

And in that sense, the right tool that fits the job often includes an analysis on popularity, especially because the best tool is often one that you and your colleagues already know.

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

#468

Post by hasanhaja »

docmars wrote: post #353
pyman wrote: post #285

Earlier quoted context omitted.

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

But this is exactly the point of the article. That'd be like if I needed to build a car, I started with a rocket blueprint in case I also need to go to space in the future.

The cost of speculating a highly interactive site that users will want to interact with is a suboptimal baseline experience until you get there. Provided you get there without losing users, it'll still be a subset of your audience that use your thing in a way that truly offsets all of these costs. If that works for your product/business, then awesome! But if these costs are too high and will hurt your product, then you need to be a lot more deliberate about how you engineer it.

I typically approach the problem first and see what tools work best to solve the problem, rather than work backwards from my preferred set of tools.

> Once you've dug that hole, you either have to live with it, or face a painful rewrite later.

Based on the tools you mentioned familiarity with, wouldn't something like Astro be a happy middle ground? You start as an MPA by default and only add complexity to parts (entire routes or parts of a page) of the application that require it? Also, this hole goes both ways. If you've built your site as a SPA, and you realise that your product just needs to be HTML to stay competitive, it's a painful road to unpick the layers of abstraction you've bought if you don't wanna rewrite it.

> dynamic features, anything from basic showing / hiding of content, list / configuration-based rendering, or requesting data

What would a highly dynamic feature be in your opinion and how does a SPA framework help you? All of the examples mentioned here, in my opinion, are fantastic candidates for server side templating and progressive enhancement. I don't need see the need for the SPA architecture here.

> mobile devices in low-bandwidth areas

Curious to know what kind of devices are present in your area? The implications of larger applications is both network and CPU [1], so if you live in a relatively wealthy area (say over 75% of users had iPhones) you'd notice the negative effects of too much JS less. If you're in the public sector or building for the public, then you can't get away with the excuse that people on slow devices and networks aren't your target audience; you need to meet everyone where they're at. A HTML-first architecture is a better and more inclusive baseline for all.

[1] https://infrequently.org/2024/01/performance-inequality-gap-...

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

#469

Post by hasanhaja »

8n4vidtmkvmk wrote: post #459
wild_egg wrote: post #455

Earlier quoted context omitted.

> I don't have stats to back that up. Your comment then falls under my "superstition" label. My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.…

For first load, yes. The idea is that you never have to send the template again after that. Cascading is a separate problem. You can bundle all the data into a single request if you want. You can even send JSON along with the HTML in the first request.

Why does this have to be the baseline architecture when you can render the HTML on the server with the template and data? Why send the data and the JavaScript to parse that data and transform it into HTML in a users browser when you can do it on the server?

For requests after the first, you can still continue to send the rendered HTML to be placed into the document. Here's an example using HTMX: https://htmx.org/examples/lazy-load/

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

#470

Post by hasanhaja »

goatlover wrote: post #367
8n4vidtmkvmk wrote: post #228

Earlier quoted context omitted.

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.

Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.

No, but doing the rendering through JavaScript in userland will be slower than letting the browser handle it
Post reply on HN