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

121–130 of 637 posts

Re: SPAs Were a Mistake

#121

Post by 9wzYQbTYsAIc »

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…

> Exactly. I've been in the position various times

This is why React is such a popular JavaScript framework of libraries.

Re: SPAs Were a Mistake

#122

Post by mithr »

If the choice was between building a traditional app from scratch, or building an SPA from scratch, then I think the article would have a solid leg to stand on: building an SPA from scratch does involve finding ways around things that browsers provide out-of-the-box.

However, pretty much no one writes SPAs from scratch, and there exist many very popular frameworks that handle the vast majority of the common SPA tradeoffs out-of-the-box, so that in reality, you don't really have to think about e.g. whether links are internal or external.

That's not to say that SPAs are always a good idea, or that they do everything well — the author's point about scrolling to the right place, especially when navigating backwards and forwards, is one thing that many SPAs don't get right, for example. And the rise of next.js and the like have shown that there are other benefits to hybrid approaches, as well, and there isn't a one-size-fits-all solution.

As for why SPAs have become so popular, I think this can be summed up pretty neatly: everything is code. There's something appealing to a software engineer about being able to control everything about how your app behaves, control when and how it loads or preloads data, how navigation works, etc. This comes with tradeoffs, you have to be careful about breaking user expectations and making things accessible, and if you go too far you can end up with a big mess ("just because you can make everything custom doesn't mean you should"), but that underlying freedom to make those choices is appealing.

Re: SPAs Were a Mistake

#123

Post by jtsiskin »

Jenk wrote: post #18

It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client. Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.

This is completely inaccurate. Every millisecond of load time affects conversion so much that they would trade huge amounts of CPU to speed up a page load.

Re: SPAs Were a Mistake

#124

Post by osrec »

It is annoying to see titles such as this, since SPAs are most certainly not a mistake (the article itself points out that the Youtube SPA is not a mistake).

The truth is most devs struggle to implement SPAs well. To implement an SPA well, you need to understand browser APIs extremely well (such as the History API), and in my experience, most devs don't, hence the broken back buttons etc.

To me, there is nothing nicer than a well made SPA, and often, the best SPAs are faster and lighter than the desktop apps they replace. I believe they are the best way to deliver software in the current age, and the sandbox that the browser offers actually provides users with a more secure execution environment than traditional software delivery mechanisms.

I personally LOVE SPAs.

Re: SPAs Were a Mistake

#125

Post by freedomben »

horsawlarway wrote: post #99
freedomben wrote: post #68

Earlier quoted context omitted.

Have you tried to use a heavily SPAed site from a slow, distant (high latency), or metered connection? A SPA that works and feels great from a big city quickly becomes unbearable when internet access isn't as ideal. There are ways to handle this nicely, but maybe 5% of devs actually think about and test that, and no PM will allocate sprint time for it.

Yes - that's literally exactly what I talked about. I can tell you - My app renders immediately in these cases, precisely because I lean heavily on a cache. I preload basically all the data a user might need at startup (prioritizing the current page) and then optimistically render from cache. I'm very familiar with these kind of situations (I have developed software designed explicitly to handle offline-only cases, a…

Awesome, thank you for doing that! I wish more people did. I've had several people tell me that "in a web app you only want to load the data you need, at the time you need it" and I die inside a little.

Re: SPAs Were a Mistake

#126

Post by zozbot234 »

hinkley wrote: post #107
horsawlarway wrote: post #65

Earlier quoted context omitted.

> Unless their cache is cold and then they navigate back before your first render completes. This doesn't matter. It's an SPA - my js context hasn't been wiped because I'm not letting the back button eat the whole thing and start over. I just complete the request and store in cache either way, and next time they hit it, it will be there. > Often we are not the sole source of a piece of information and first load time…

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…

To be fair, there are SPA frameworks that try to minimize the amount of logic that's shipped to the client, Svelte is an example, which should be as lean and efficient as any hand-coded JS. It's more of a side effect of what frameworks you use than SPA per se.

Re: SPAs Were a Mistake

#127

Post by amelius »

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…

Yes. The fitness of an architecture can be partially measured by looking at the cost of feature updates.

Re: SPAs Were a Mistake

#128

Post by onaworkcomputer »

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…

> The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly.

Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliably instantaneous than the bespoke caching solutions each SPA seems to invent for itself.

Re: SPAs Were a Mistake

#129

Post by horsawlarway »

hinkley wrote: post #107
horsawlarway wrote: post #65

Earlier quoted context omitted.

> Unless their cache is cold and then they navigate back before your first render completes. This doesn't matter. It's an SPA - my js context hasn't been wiped because I'm not letting the back button eat the whole thing and start over. I just complete the request and store in cache either way, and next time they hit it, it will be there. > Often we are not the sole source of a piece of information and first load time…

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 start of the day, vs pulling your fucking hair out all day long.

Re: SPAs Were a Mistake

#130

Post by Zanfa »

ysavir wrote: post #113
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…

> Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works fine, but then you get to browser navigation and you're screwed, because none of this works out of the box if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken…

> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect?

In my specific example, the navigation itself didn't happen through JS, but you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit. To make things even more fun, Turbo/Stimulus (sometimes?) breaks bfcache in Safari & Firefox so they behave different from Chrome.

Personally, I detest the vast majority of SPAs, especially the ones from Google, Facebook and Linkedin. Not even sure what they do to make them so horribly slow to use.

Post reply on HN