Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

51–60 of 637 posts

Re: SPAs Were a Mistake

#51

Post by hinkley »

horsawlarway wrote: post #45
zozbot234 wrote: post #14

Earlier quoted context omitted.

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

Unless their cache is cold and then they navigate back before your first render completes. Often we are not the sole source of a piece of information and first load time counts.

Re: SPAs Were a Mistake

#52

Post by clivestaples »

I think SPAs were the best solution we had at the time and I enjoyed trying to build good UX with them. Yes, React started fresh and ended up driving me back to Rails because I'm just not smart enough. That said, I am really excited about Django w/HTMX, Rails w/ Hotwire, and Next and Remix with React. Particularly Remix.

Re: SPAs Were a Mistake

#53

Post by commandlinefan »

aminerman wrote: post #28

Anyone can choose the tech stack, patterns, or whatever that he likes. But developers enjoy being absolutists, and deem something they don't like as a MISTAKE, or would tell you that the way they think is the ONLY way to think. You do your app the way you want depending on the Ux you want to provide, on the tech you enjoy implementing, on the patterns you like to follow.

> Anyone can choose the tech stack, patterns, or whatever that he likes

Maybe for personal projects, but 99% of us have to use the tech stack, pattern or whatever of our employer that was decided on (presumedly by some consensus at some point in the past). Publicly pointing out the flaws in what might have made sense then but might not make sense now is a Good Thing so that those flaws might be taken into consideration in the next round of consensus building.

Re: SPAs Were a Mistake

#54

Post by horsawlarway »

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…

Yeah - I think a lot of it might be developers who don't understand that SPA and caching go pretty much hand in hand.

I'll admit that can make your life as a developer harder sometimes (to be blunt - caching is hard - full stop) but an SPA rendering from cache is basically a rocket compared to a server rendered page on a bad connection.

Absolutely no one enjoys waiting 2-5 seconds after clicking the back button to see a page they were just on, but that's the reality of a server rendered app on a bad connection. An SPA with good caching does, in fact, feel like a native app - in lots of good ways.

Re: SPAs Were a Mistake

#55

Post by xwdv »

Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

This problem you described is exactly why SPAs will continue to dominate over the traditional server rendered websites.

Often when I see people arguing against SPAs, they are peddling trivial toy websites that don’t do much and don’t change much.

When you need to build a serious application on the web with quickly growing feature sets and complex state management, just use a SPA. It’s 2022.

Re: SPAs Were a Mistake

#56

Post by tonyedgecombe »

aminerman wrote: post #39
softwarebeware wrote: post #29

I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?

Quoted post unavailable.

You keep making this ad hominem attack without presenting any evidence.

Re: SPAs Were a Mistake

#57

Post by barbarbar »

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

`

Re: SPAs Were a Mistake

#58

Post by hinkley »

aminerman wrote: post #35
slashdev wrote: post #24

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…

Quoted post unavailable.

Harsh. Dude ported liveview, this isn’t amateur level work.

It’s a useful brush but you can’t use it to paint everything.

Re: SPAs Were a Mistake

#59

Post by Closi »

hombre_fatal wrote: post #17
Zanfa wrote: post #7

I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…

Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be…

I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application.

The browser multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working.

UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can be without all the cruft you have to add to make a SPA work because it's actually a sort-of-massive-workaround.

Post reply on HN