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

91–100 of 637 posts

Re: SPAs Were a Mistake

#91

Post by 8note »

freedomben wrote: post #68
horsawlarway wrote: post #45

Earlier quoted context omitted.

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…

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.

Using the web at all is your problem there.

If that's your targeted usecase, send an exe on a thumb drive, and get them to call you back over the phone

Re: SPAs Were a Mistake

#92

Post by horsawlarway »

kevinmcconnell wrote: post #63
horsawlarway wrote: post #45

Earlier quoted context omitted.

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 server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Not necessarily. I think you're conflating caching/fetching and rendering here. You can cache rendered views in the same way you'd cache the data for those views. Turbo does this, for example. When you navigate to a cached page it will display the page from the cache first, then make a request to update the cache…

Turbo is making your site an SPA, and hiding the implementation details from you

That's not what the article was about (it was very clearly advocating for the standard browser flow)

Re: SPAs Were a Mistake

#93

Post by ChicagoDave »

Users do stupid things regardless of the implementation. The extra work to implement a SPA is worth it because you can swap material in and out on demand without constructing a complete new web page.

100% disagree with OP.

Re: SPAs Were a Mistake

#94

Post by nawgz »

"SPAs were a mistake"

Meanwhile essentially every major tech property develops SPAs and users enjoy them far more than traditional hypertext web round-trip-every-change pages

Re: SPAs Were a Mistake

#95

Post by CPLX »

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…

Yeah can someone fix this please. I'm experiencing the same thing with a rails app I'm currently building.

In all seriousness it feels like there must be an elegant way to do more responsive modern functions while keeping the core server rendering concept. It's 2022 after all. But no I don't know a good solution either.

Re: SPAs Were a Mistake

#96

Post by salt-thrower »

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.

I'm sure the data that FB and Google are delivering is far more expensive than rendering HTML would be. I am skeptical that server side rendering was a big enough bottleneck for them for that to be their primary motivation. I'm also skeptical that SPA frameworks would have been widely adopted by developers all over the world if they were just some conspiratorial plot by tech companies to save on CPU cycles.

Re: SPAs Were a Mistake

#97

Post by onemoresoop »

blunte wrote: post #8

I don't disagree with most points here, but I did chuckle at this one: > YouTube is a great example. Being able to keep a video playing while you explore other videos is fantastic. I hate that (mis)feature. When I click something else, my attention is on the new thing. Having to go find the little still-playing video window to close it is a hassle.

Some like it some hate it. I hate it too but generally I like simpler things. I wish we could opt out of some features so everybody would be happy.

Re: SPAs Were a Mistake

#98

Post by root_axis »

commandlinefan wrote: post #53
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 considerati…

Don't work for a company running a tech stack you don't like.

Re: SPAs Were a Mistake

#99

Post by horsawlarway »

freedomben wrote: post #68
horsawlarway wrote: post #45

Earlier quoted context omitted.

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…

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, and I'm very familiar with how bad a connection might be in rural Appalachian schools.)

Re: SPAs Were a Mistake

#100

Post by ordinaryradical »

te_chris wrote: post #22
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…

Phoenix LiveView really does solve a lot of these problems.

I was just going to say this sounds like a great example of something that Elixir, LiveView, plus maybe a little Alpine.js could handle...
Post reply on HN