SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#41

Post by uhoh-itsmaciek » Wed, Mar 02, 2022, 5:12 PM UTC

onion2k wrote: post #2

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…

I think it's exciting to see frameworks like 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.

Re: SPAs Were a Mistake

#42

Post by antihero » Wed, Mar 02, 2022, 5:13 PM UTC

aminerman wrote: post #40

antihero wrote: post #30

This article seems to be directed at dealing with people that use SPAs to make more content focused websites, which quite obviously are better made with the browser. However, for an application with a persistent UI, I fail to see how constant page loads and navigation just because "the browser can do this" make any sense at all. Even the example is a bit silly - SPAs that should be SPAs don't really have "links" per…

He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D

It does feel like the tiring contrarianism type of heading as opposed to a particularly well thought out article.

In the same way I feel lesser able coders seem to dwell on shit-slinging against tech that is proven, works, and has solved innumerable problems when they bang on about how things were so much nicer with vanilla JS and how frameworks are lazy and slow or something, in order to cultivate a sense of superiority.

Any well made tech has it's place, skill and experience are about knowing which tech should be used where.

Re: SPAs Were a Mistake

#43

Post by midiguy » Wed, Mar 02, 2022, 5:14 PM UTC

Every week someone posts some half-baked blog ramble about how SPAs are bad (except for media sites!).

How about this - I am just as or more efficient working with SPA frameworks such as React as working with server-side-rendering. I have invested in a skill and toolset that can deliver any sort of website or web application from blogs to Youtube to Figma. I don't see any reason I would invest in learning an MPA framework that is only good for a subset of that.

If you are delivering content-only website with simple forms you might as well just use a CMS and call it a day.

Re: SPAs Were a Mistake

#44

Post by TedDoesntTalk » Wed, Mar 02, 2022, 5:15 PM UTC

mi100hael wrote: post #16

I think people have forgotten how easy it is to set up a traditional server-rendered site with Spring Boot or Django or whatever framework. These days I see people adding a SPA as the default starting approach, which adds an entirely separate additional tech stack & deployable to the mix when it's not usually clear why.

If you don’t start with an SPA, you are looked at funny. Like maybe if you were to choose COBOL for the backend code.

Re: SPAs Were a Mistake

#45

Post by horsawlarway » Wed, Mar 02, 2022, 5:18 PM UTC

zozbot234 wrote: post #14

onion2k wrote: post #2

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…

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

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.

Re: SPAs Were a Mistake

#46

Post by frabjoused » Wed, Mar 02, 2022, 5:19 PM UTC

I can't agree with this. That list of 9 complexities are well abstracted by the most common library or framework for SPAs. Having done a lot of SPA development I can say routing is not anywhere up on the list of trouble spots you do encounter. State management is another story.

Re: SPAs Were a Mistake

#47

Post by hinkley » Wed, Mar 02, 2022, 5:22 PM UTC

zozbot234 wrote: post #14

onion2k wrote: post #2

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…

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

People generally have a very bad estimate of just how engaged users are with their sites.

These people have lives and other shit to do besides spend all day in my web app. There’s a lot more accidental and exploratory clicks than you think and all of the background requests run even though the user is only on that page for half a second.

Re: SPAs Were a Mistake

#48

Post by midiguy » Wed, Mar 02, 2022, 5:23 PM UTC

tofuahdude wrote: post #33

a_chris wrote: post #23

The problem with SPAs is that they have been misused and overused, at least in Italy. Tons of projects built with SPA in which we have to re-implement basic browser features like the back button, just because project manager has no idea of how this technology works. I've worked on at least 4 projects which could be written in Nextjs in half of the time

Hate to break it to you but Nextjs is for building SPAs.

I was going to say.... ironically NextJS is just an additional layer for creating static-rendered sites over an SPA framework. We have come full circle.

Re: SPAs Were a Mistake

#49

Post by stevebmark » Wed, Mar 02, 2022, 5:23 PM UTC

Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet.

SPAs and Jamstack favor developer convenience over end user experience. Let's have fewer loading spinners, and more SSR-by-default for pages with dynamic content.

Re: SPAs Were a Mistake

#50

Post by tonyedgecombe » Wed, Mar 02, 2022, 5:23 PM UTC

onion2k wrote: post #2

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…

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