Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

471–480 of 516 posts

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

#471

Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the for…

SPAs do not exist to benefit the user. They exist to benefit the developer who writes them.

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

#472

Earlier quoted context omitted.

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

> wouldn't something like Astro be a happy middle ground?

Absolutely, but it is additional boilerplate I have to worry about that serves as another layer alongside whatever SPA framework I prefer; whereas spinning up a Vite template with Vue, writing a few routes + components, and getting it built + deployed is easier. It's at such a low cost (bundle size, time, boilerplate) that the optimizations gained from Astro aren't even in my purview unless I'm experiencing a significant enough scale that justifies static rendering.

When my apps are feeling and behaving perfectly already, why optimize? It only comes with increased scope and cost to bend around another layer.

> If you've built your site as a SPA, and you realize that your product just needs to be HTML to stay competitive

This does go both ways, yes, but with SPAs, I have more flexibility around client-side features like transitions, animations, pagination for smaller datasets, and state-based views that depend on a lot of different interactions, user selections, etc. that all drive what gets displayed instantly, without making a single network request just to complete the interaction. The Venn diagram between the two shows SPAs doing more out of the box, at such a low cost to commit.

Whereas with MPAs and server-side templating, a better-feeling UI isn't a luxury you can enjoy without some form of JavaScript to wire up page interactions. Given these are often a requirement, you'll find yourself haphazardly adding an SPA library to an existing MPA to enhance the perceived UX that it couldn't provide. Then you're not only juggling 2 scripting languages, but also reconciling the separation of concerns between your client/server now.

Although, happy-mediums have emerged: 37signals created Hotwire to help bridge this gap, Laravel has a similar library Intertia.js, and htmx+Alpine is another interesting solution.

Lastly on this point, Svelte's build step strips your SPA into the smallest possible runtime. Svelte was actually built for creating SPAs intended to run on low-power devices [1] typically seen in places like LATAM. React also has an official compiler that memoizes component data and callbacks. Preact is a 3kb alternative to React (40kb) for low-power devices, sharing the same APIs with only a few minor differences.

React, Vue, and Svelte all have server-side rendering where you can comfortably write sites/apps that serve up smaller bundles and stream updates to the client as needed, without sacrificing a pleasant UX. So, to answer your question "what if your SPA needs to be HTML to stay competitive?" -- these are all the most sustainable paths with the lowest costs.

>> You may be asking, "why don't you learn + use some of the alternatives you listed?"

As any reasonably tired, middle-aged engineer would say: I'm happy with the language(s), tools, libraries, and frameworks I'm comfortable using. The incessant drive to learn new tools that pretty much do the same thing with dubious (and likely negligible) benefit at smaller scale feels like a distraction when I could just be building and shipping something with familiar tech that thousands of other developers enjoy using. I also benefit from the community support as well, not to mention, AI tools are best used in TypeScript codebases currently.

Server-side templating requires dedicated hosting / VPS, which is a whole 'nother layer of deploying, managing, and debugging. Static sites and SPAs can be hosted with a static host for free (unless you scale like crazy), and any data-related needs are solved with serverless services like Supabase, Convex, lambdas/functions, and any number of others -- all with generous free plans and some level of portability.

In my case, I'm only developing SaaS applications not needing mobile support, that are only used by companies that buy decent computers for their employees. Otherwise I'm building small webapps for personal use and some that may become a hit among niche communities. Even my personal site is a tiny Vue app, and only because it's familiar and easy to change. The performance fiends can cry all they want that it isn't purely static, and in many ways, that amuses me.

[1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...

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

#473
post #418

Earlier quoted context omitted.

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…

I agree. There's a rich ecosystem for building SPAs with MACH architecture. There’s no going back now, not even for basic apps.

For scale, this is the easiest approach. Teams can focus on their roles and specialize more, which leads to higher efficiency as team members build their rhythm and stay focused on what they're great at.

At my company, our React SPA uses just over 500+ components across maybe ~30 views, with many smaller components alongside many of them in the same files. Our bundle size is obscene, but our customers are using fast PCs on fast connections. Once it's cached, they're good -- and each new release is roughly every 2-4 weeks, so fresh visits are painless.

As for server-side rendering from RSC, Next, Nuxt, and SvelteKit, I'd say they're overkill in most situations. The amount of people deploying simple sites on Vercel using Next.js, not really using its features, is just silly (and costly).

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

#474
post #464

Earlier quoted context omitted.

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

I don’t see anything on that site that wouldn’t work as a website. We were building this type of thing 15-20 years ago just fine.

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

#475

Earlier quoted context omitted.

But even the most well optimized nextjs/react 'blog' or ecom site performs and order of magnitude worse than a SSR version, simply because you have to bring in runtime stuff? I'm giving extreme examples; but I've seen very very able development teams totally shoot themselves in the foot with this.

Next/React sites can be SSRd just fine. If a db call is slow it's going to be just as slow for a PHP page as for a React page.

But even if you SSR them you still need to send at least 100KB (and probably far more) of JS down to the browser to hydrate state and handle any interactivity.

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

#476

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.

> The idea is that you never have to send the template again after that.

This implies or assumes that sending the template again is a problem. In practice, it's not. HTML compresses well and the difference between the compressed JSON and HTML response is often on the order of hundreds of bytes. That assumes equivalent data content which, as I've said above, is often not the case. JSON payloads tend to be larger and we need more of them to render the same UI.

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

#477

Earlier quoted context omitted.

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.

They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.

Why on earth would you do a full page refresh on every interaction? Browsers have native support for partial page updates and prefetching.

JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.

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

#478
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 o…

In my experience, state is the devil, and the approach of filtering things on the client moves a bunch of state management from the back end to the browser, which is the worst place to handle state.

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

#479

Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the for…

I like the pushback because it means less competition in the native framework space

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

#480

Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the for…

if you're receiving jarring page scrolling, it is not the fault of the spa, it's something else at play. it is not they typical spa experience.

if the back button doesn't work, the site was poorly programmed, since any routing library will handle that for you.

Post reply on HN