Comment by traverseda | Hacker News Reader

Comment by traverseda | Hacker News Reader

Parent Full thread

>If your problem and requirements are such that you will always be outside the part of the solution space that SPAs are meant for

That seems like a very very strong claim. "You should do an SPA in case you ever need to make an SPA". Like what do you think actually needs to be an SPA?

Here's my list of popular sites that don't need to be an SPA but are anyway

* Reddit, nothing about it lends itself to being an SPA at all.

* Facebook, I think they went the SPA route in order to make it more difficult for ad blockers

* instagram

* Netflix (don't know how related this choice is to DRM constraints honestly)

* pinterest

* paypal

* gmail

Here's my list of sites that do need to be an SPA, or are at least easier if you make them as an SPA.

* Google maps

* Google docs

* Photopea

* Discord (This is almost all achievable with something like HTMX, save the webrtc stuff, but I think it would be more of a pain and would rely on a lot of complicated session management stuff happening on the server)

* AirBnb, which I'll give a pass since it makes such heavy use of maps.

My take away is that if you're reaching for the standard SPA toolkit you might be better off using something like QT or Godot engine, writing native code, and compiling it for the web. Anything that uses maps or rich text editing probably should be done as an SPA, although if you can make it so that just the one component is "rich" you should probably do that.

Using more complicated components can be a reasonable idea, like using a graphing widget or a maps widget, but you can do those things without making your entire app an SPA.

I just don't buy the "you might need to make your app an SPA some day to you might as well take on the technical burden from that decision now" idea. Very very few projects need to be an SPA, and when you have one it's probably pretty obvious.

> I just don't buy the "you might need to make your app an SPA some day to you might as well take on the technical burden from that decision now" idea.*

I'm not selling that idea. "Boil the ocean now in case you want a cup of tea tomorrow" is a fantastically effective way to fail.

>> If your problem and requirements are such that you will always be outside the part of the solution space that SPAs are meant for

> That seems like a very very strong claim.

By that wordy garbage I was trying to contrast the very extreme, where HTMX is an obvious fit, with points further down the spectrum where it's not so clear. You could go full SPA on an HTMX-shaped problem, if you wanted to, or full progressive enhancement on an SPA-shaped problem; I can't think of any technical thing that would stop you. There would just be consequences and it's up to you if they're worth it.

> Like what do you think actually needs to be an SPA?

I think a move to SPA gets more attractive when you have 1) ad-hoc client-only state 2) that shouldn't be explicitly reflected in your server-side data model 3) produced without coordination by different independently-enhanced components sharing a page 4) which causes unexpected interactions between them.

SPA is not the only way to solve that, solving it is not the only benefit of SPA, you could just ignore it and accept the combinatorial growth of your state space, a hundred other caveats. It's an engineering question which should get an engineering answer maximizing benefit by balancing tradeoffs, but IMO that's not the treatment it usually gets.

>I think a move to SPA gets more attractive when you have 1) ad-hoc client-only state 2) that shouldn't be explicitly reflected in your server-side data model 3) produced without coordination by different independently-enhanced components sharing a page 4) which causes unexpected interactions between them.

That's a lot of what I was thinking about when I was thinking if discord really needed to b an SPA, all that ad-hoc client state would need to be reflected on the server.

Non-SPA feels slow. It doesn't matter that much if it's slower or not, because the perception is slow. If I'm on a page, click on something, and in the background it loads some new content and updates part of (or even the entire) page, at least while I'm waiting, there's usually something else to read or potentially interact with in some way. Maybe there's a spinner for requests over ~200ms. It feels like the app is doing some work but it otherwise present. If every click results in a new page render, my browser immediately clears the page and I'm left looking at a blank page waiting for content to render. Even if that somehow takes half the time, it feels like an eternity, and there's nothing for me to look at while I wait. And that full-page redraw is visually distracting.

Many SPAs I use feel glacial compared with MPAs. You can tune either approach and htmx apps take away the clunkiness of full page refreshes.

Reply on news.ycombinator.com