7 ms·

SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essen

SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. They might not be actual requirements for a blog or a brochure site but it's not totally unreasonable for someone to want their website to work that way. The question is not whether or not an SPA is a good or a bad thing, but whether or not the cost (more code, more complexity, potentially a series of background requests after the initial page load) is worth paying in order to get the benefits. When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. That should be the goal. Make stuff where the user forgets about the tech. Make a website that just works, that's fast enough for users not to think 'this is a bit slow', and that's coded in a way you can maintain and work on for a long time. If you get those things right then no one can reasonably criticise what you've made no matter how you've made it.

midrus 5y ago
> they work if your connection is flaky, Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.
zozbot234 5y ago
> the idea of essentially removing the network round trip when a user clicks on something is not a bad one. Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.
- deleted 5y ago
  [deleted]
- tiborsaas 5y ago
  SSR isn't a one-size-fits-all solution. Blogs? Sure. Corporate marketing site? Absolutely. Wikipedia? What else. A webapp where state can exist in various components is a perfect fit for SPA-s. Clicking a button in a widget and submitting the page with every other state, updating them and refreshing the page makes no sense. SPA-s also help with separating frontend and backend development, they are different beasts. I know many backend devs who wouldn't touch frontend with a 10m pole and not because of JavaScript, but because they don't like design and UX in general.
- horsawlarway 5y ago
  I pretty strongly disagree with this. The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win. The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Still doesn't make an SPA the right fit for everything, but on bad networks, we get incredibly improvements in performance by rendering from cache, and occasionally handling cache updates in the background. User's fucking love it compared to waiting 2-5 seconds for every page load, even if they were JUST on the page a second ago.
  - midrus 5y ago
    > done correctly Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive. I can also assure you that when an MVC application is done correctly you can have an equally good user experience. > The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc. I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.
uhoh-itsmaciek 5y ago
I think it's exciting to see frameworks like https://remix.run/ https://remix.run/ trying to temper the disadvantages of SPAs by relying on web standards and server-side rendering. It's pretty cool that this is a JavaScript framework that can work without any (client-side) JavaScript.
- freedomben 5y ago
  Honest question: why is remix the primary example for this now? Next.js has been doing this for years and is really amazing. It seems like a ton of people had no idea this was even a problem they had until remix came along, and now remix is the savior. Am I missing something with remix? Is there anything really novel that it does/introduces?
  - uhoh-itsmaciek 5y ago
    I don't know. I'm not very familiar with Next.js (I'd heard about it but never really looked into it much). Your response inspired me to investigate, and I found an article by a Remix founder about the differences [1]. It's obviously biased, but maybe still interesting. It looks like there was an HN submission and a bit of discussion, too. There's a bunch of other comparisons out there, too. [1]: https://remix.run/blog/remix-vs-next https://remix.run/blog/remix-vs-next [2]: https://news.ycombinator.com/item?id=29983950 https://news.ycombinator.com/item?id=29983950
  - pl0x 5y ago
tonyedgecombe 5y ago
>It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. Yet the reality seems to be the opposite. If my connection is flaky (which it often is) then SPA's seem to fail more often and it isn't obvious what is going wrong. They don't seem to be faster either, long pauses between pages is common.
- zozbot234 5y ago
  Right. The typical SPA doesn't recover at all from network failures, and you end up poking random buttons hoping that it will reach some sort of consistent state. Then you find that doesn't help and you need to refresh anyway, which is a reboot for the whole 'app'. So much for saving page loads.
RHSeeger 5y ago
> When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. And therein lies the problem. In the _vast_ majority of SPA sites I've been to, they are not "well done" by this definition. It is commonplace for things to break, like the back button as the quintessential example, because the developer(s) didn't spend the time to make sure things work correctly. With a non-SPA site, you generally have to go out of your way _to_ break those same things. I like SPAs for some things (gmail being a good example), but they should not be the default implementation; there should be a _very_ strong argument before the SPA architecture is used.
- gowld 5y ago
  You're just saying that bad software is bad. That's tautological. Without SPA you have horrific 10page forms and the challenge of maintaining state as you go back and forth to make edits. The hard part is managing state, and there is no way to avoid it if your product is not purely readonly. SPA is one strategy, and a pretty good one.
  - onaworkcomputer 5y ago
    The GP was not saying "bad software is bad"; they pointed out a lot of footguns that are introduced by going the SPA route. "More code -> more (opportunities for) bugs" is the truism at play here.
  - acdha 5y ago
    If one style of writing applications is far more prone to having “bad software”, consider that this is a valuable signal about the difficulty of using that style effectively. SPAs require you to take on ownership of more hard to debug challenges and that's an important factor to consider when selecting tools.
eithed 5y ago
Those are very good points - I wonder how the author would see, for example, Google Sheets implemented as not a SPA

midrus 5y ago

> they work if your connection is flaky, Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.

zozbot234 5y ago

> the idea of essentially removing the network round trip when a user clicks on something is not a bad one. Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.

deleted 5y ago
[deleted]
tiborsaas 5y ago
SSR isn't a one-size-fits-all solution. Blogs? Sure. Corporate marketing site? Absolutely. Wikipedia? What else. A webapp where state can exist in various components is a perfect fit for SPA-s. Clicking a button in a widget and submitting the page with every other state, updating them and refreshing the page makes no sense. SPA-s also help with separating frontend and backend development, they are different beasts. I know many backend devs who wouldn't touch frontend with a 10m pole and not because of JavaScript, but because they don't like design and UX in general.
horsawlarway 5y ago
I pretty strongly disagree with this. The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win. The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Still doesn't make an SPA the right fit for everything, but on bad networks, we get incredibly improvements in performance by rendering from cache, and occasionally handling cache updates in the background. User's fucking love it compared to waiting 2-5 seconds for every page load, even if they were JUST on the page a second ago.
- midrus 5y ago
  > done correctly Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive. I can also assure you that when an MVC application is done correctly you can have an equally good user experience. > The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc. I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.

uhoh-itsmaciek 5y ago

I think it's exciting to see frameworks like https://remix.run/ https://remix.run/ trying to temper the disadvantages of SPAs by relying on web standards and server-side rendering. It's pretty cool that this is a JavaScript framework that can work without any (client-side) JavaScript.

freedomben 5y ago
Honest question: why is remix the primary example for this now? Next.js has been doing this for years and is really amazing. It seems like a ton of people had no idea this was even a problem they had until remix came along, and now remix is the savior. Am I missing something with remix? Is there anything really novel that it does/introduces?
- uhoh-itsmaciek 5y ago
  I don't know. I'm not very familiar with Next.js (I'd heard about it but never really looked into it much). Your response inspired me to investigate, and I found an article by a Remix founder about the differences [1]. It's obviously biased, but maybe still interesting. It looks like there was an HN submission and a bit of discussion, too. There's a bunch of other comparisons out there, too. [1]: https://remix.run/blog/remix-vs-next https://remix.run/blog/remix-vs-next [2]: https://news.ycombinator.com/item?id=29983950 https://news.ycombinator.com/item?id=29983950
- pl0x 5y ago

tonyedgecombe 5y ago

>It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. Yet the reality seems to be the opposite. If my connection is flaky (which it often is) then SPA's seem to fail more often and it isn't obvious what is going wrong. They don't seem to be faster either, long pauses between pages is common.

zozbot234 5y ago
Right. The typical SPA doesn't recover at all from network failures, and you end up poking random buttons hoping that it will reach some sort of consistent state. Then you find that doesn't help and you need to refresh anyway, which is a reboot for the whole 'app'. So much for saving page loads.

RHSeeger 5y ago

> When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. And therein lies the problem. In the _vast_ majority of SPA sites I've been to, they are not "well done" by this definition. It is commonplace for things to break, like the back button as the quintessential example, because the developer(s) didn't spend the time to make sure things work correctly. With a non-SPA site, you generally have to go out of your way _to_ break those same things. I like SPAs for some things (gmail being a good example), but they should not be the default implementation; there should be a _very_ strong argument before the SPA architecture is used.

gowld 5y ago
You're just saying that bad software is bad. That's tautological. Without SPA you have horrific 10page forms and the challenge of maintaining state as you go back and forth to make edits. The hard part is managing state, and there is no way to avoid it if your product is not purely readonly. SPA is one strategy, and a pretty good one.
- onaworkcomputer 5y ago
  The GP was not saying "bad software is bad"; they pointed out a lot of footguns that are introduced by going the SPA route. "More code -> more (opportunities for) bugs" is the truism at play here.
- acdha 5y ago
  If one style of writing applications is far more prone to having “bad software”, consider that this is a valuable signal about the difficulty of using that style effectively. SPAs require you to take on ownership of more hard to debug challenges and that's an important factor to consider when selecting tools.

eithed 5y ago

Those are very good points - I wonder how the author would see, for example, Google Sheets implemented as not a SPA