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

231–240 of 637 posts

Re: SPAs Were a Mistake

#231

Post by sinker »

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.

Next.js recommends delivering static assets by default and is geared towards that.

> We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.

If you need dynamic content, they recommend server-side rendering, and lastly client-side rendering only if the page is unaffected by SEO and requires a lot of in-page updates.

https://nextjs.org/learn/basics/data-fetching/two-forms

Re: SPAs Were a Mistake

#232

Post by SinParadise »

prmph wrote: post #167
dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

>app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA.

I agree with this because you affirm my bias.

Also because I've also had success implementing this structure. This makes sure that state of each page doesn't leak everywhere, which simplifies the state management.

It also loads faster than a big SPA because you don't have to worry about bundle splitting!

Re: SPAs Were a Mistake

#234

Post by abemassry »

candiodari wrote: post #193
bastawhiz wrote: post #139

Earlier quoted context omitted.

> 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. This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progre…

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does). SPA: 1. get html from server (1 roundtrip) 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip) 3. get ajax calls from server (1 roundtrip) 4. process answer from server + update page (not a roundtrip, but not zero) Vs traditional: 1. get html from server (1 roundtrip) 2. get resources f…

I wrote a post very similar to this comment that you might be interested in reading. I broke down what takes time to load, how fast the browser determines something has loaded, and how fast the user can perceive the page loading. I ended up having to take a high speed video and measure frame by frame the time it took to load for user perception.

https://www.ireadthisweek.com/author/ireadthisweek/post/2022...

The TLDR is it takes longer than reported.

Re: SPAs Were a Mistake

#235

Post by NoGravitas »

horsawlarway wrote: post #129
hinkley wrote: post #107

Earlier quoted context omitted.

It doesn’t matter‽ SPAS push giant gobs of logic and CSS ahead of the Time To Interaction and cross their fingers that nobody will notice because it’s not supposed to happen the next time due to magical cache thinking. People have been ignoring actual research on caches for the entire time SPAs have been around. First time visitors have this as their first time visit. Occasional visitors show up after the last deploy…

Look - I understand that I'm making a tradeoff here, and I'm very clear that not all sites are the right fit for an SPA. But yes - I explicitly handle offline-only use cases, and god-damned terrible connections (think They call in excited as all get out when they realize they only have to wait once with my application, and not once every page load. It's the difference between having a chance to grab a coffee at the s…

Your application seems to be a magical unicorn (not being sarcastic!). Most SPA websites I use on a regular basis end up having to reload all of their page components every visit, and frequently on every 'back'.

Re: SPAs Were a Mistake

#236

Post by ithrow »

dlisboa wrote: post #155
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…

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Agree, we just add React components here and there to server-side rendered HTML and it works great for us. The issue is most companies want separate teams for front-end and back-end and each team wants clear separation of boundaries and responsibilities between them.

Re: SPAs Were a Mistake

#237

Post by manigandham »

mattmanser wrote: post #201
hughrr wrote: post #178

Earlier quoted context omitted.

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

Asp.net web forms absolutely sucked. They fundamentally misunderstood HTML and how the internet even worked. Modern Razor's pretty good (not Razor Pages, they also suck) which is probably what you mean. But it's not that much different from Rails, Laravel, Django, etc.

What’s wrong with razor pages? They’re fantastically simple and productive.

And WebForms wasn't a misunderstanding. It was a deliberate and brilliant design that brought WinForm developers and their experience to the web and allowed them to build complex web apps two decades ago that still work to this day.

Re: SPAs Were a Mistake

#238

Post by manigandham »

hughrr wrote: post #178
prmph wrote: post #167

Earlier quoted context omitted.

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

Why does it kill you to say that? It’s the better and more productive option.

Re: SPAs Were a Mistake

#239

Post by hughrr »

manigandham wrote: post #238
hughrr wrote: post #178

Earlier quoted context omitted.

The correct answer for this stuff, and it absolutely kills me saying this, is probably something like asp.net web forms.

Why does it kill you to say that? It’s the better and more productive option.

Because I abandoned it thinking it was terrible. Then I spent a decade finding out how bad everything else was.

Re: SPAs Were a Mistake

#240

Post by acdha »

horsawlarway wrote: post #116
giantrobot wrote: post #114

Earlier quoted context omitted.

> 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 data is never in the cache. It is for a developer because they forget to clear their caches when testing. For most users the data will not be cached unless they're sitting on the SPA all day. So when the user doesn't have data cached that 3xRTT on…

>The data is never in the cache. Then you have a shitty app. Between localstorage and indexdb - unless you're literally out of disk and having storage being evicted, then if you've loaded my app once (and I mean once , not once this browser session) then I have data in cache. Basically - don't blame SPAs, blame developers for assuming that the same "request the data every page view" paradigm is still in play. It's no…

> Then you have a shitty app.

This feels a lot like you're making a “No True Scotsman” argument. The behaviour you're saying doesn't / shouldn't happen has been the defining characteristic of SPAs since the beginning and it's still immediately visible on most of them as soon as you have a less than perfect high-speed internet connection. If statistically nobody except the Wordle developer can make something which handles crappy WiFi the problem requires more than just saying someone is a bad developer.

Post reply on HN