Comment by horsawlarway
4 years ago
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.
> 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.
How does that work if a user is logged in and private data is visible on the page?
I’m thinking of building something that only renders public data on the server, and then later gets that which pertains to individuals through an API. But I don’t want to spend more time on a lot of complicated plumbing than on core functionality in my application.
A SPA seems like the path of least resistance here, since all you have to do is put the appropriate cache control headers on your API endpoints, and let the browser abstract it away for you. I know programmers like to build bespoke caching solutions, been there, done that, but you don’t actually need to.
My biggest gripe with SPAs is the overhead of building and maintaining an API for everything, but GraphQL takes away a lot of that pain.
I've seen a lot of projects that use a full response cache to capture a view with holes where user-specific information would go and then fill in those holes with some client side JS. I wouldn't call those SPAs, though.
But I'd say it's more common to just use "private" cache headers in this case for any page that differs for logged in vs unauthenticated users. The user's browser will still serve as a full page cache, but shared caches will ignore those pages.
GraphQL is a protocol, as such it cannot take away the pain of creating a backend for your frontend.
There are tools which make the creation of the backend painless and utilize GraphQL for sure (i.e hasura), but claiming that GraphQL solved that issue is nonsensical, because writing the GraphQL API is generally way more annoying then the equivalent rest API is
1 reply →
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.)
> I preload basically all the data a user might need at startup
This can be a great strategy when you're dealing with bounded data that's not sensitive, but it's important to recognize that this approach is often inappropriate. A web app may be allowing users to wander around terabytes of data, or it may need to make highly consistent authorization determinations before allowing a user to see specific data, or you may need to keep a highly detailed audit log of who requested what when (e.g., if the app targets healthcare or government users), which aggressive preloading would render useless.
3 replies →
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.
This works great as long as it is not a first visitor though. For new visitors with a spotty connection this will be a nightmare. Also I assume any new update you release which might need to refresh the cache would also be a problem in this situation. I don't think it's that easy. Not saying that you're not doing it right, just that it is not a trivial thing and almost everyone else won't do this right.
In case of slow internet, SPAs are much easier to make responsive than an SSR application.
Sure, if that's your goal. It won't happen by accident, and the "default" method of SPAs make it really easy to fire off lots of different requests, often on demand.
1 reply →
Have you tried to use a site that reloads all the data on every click, from a slow, distant (high latency), or metered connection? Same problem.
Of course, and it's usually not as big of a problem because everything you need comes in the page render. With SPAs it's not uncommon to have to click 5 or buttons/menus and then wait for data to load, then click again, and more data.
That said there are plenty of SSR sites that are terrible too. It's not the technology that's at fault, but SPAs and common dev patterns in the community definitely enable and encourage making lots of small requests.
2 replies →
It's not that SPAs cannot handle that but it's rarely a requirement.
I've once launched a product on (early days) Google App Engine and it was unusable as purely server-side rendered website because sometimes it would take ages to load or worse an error would come up eventually. With AJAX it could be solved and failing requests could be repeated. It's a pity that this is rarely done but it is of course possible.
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
I know this is/was not your intention, but to be honest, I find that attitude insulting and frankly discriminatory.
The internet has become essential to modern life, and many people have no choice but to use it. Most of my monthly bills don't have any alternative to paying online. (Some will take a payment by phone but they'll charge a $20 "phone fee" or similar).
There are certainly sites/apps that just can't work without requiring a big and short pipe, but it's extremely defeatist to suggest that it's hopeless and we shouldn't even try.
You're certainly not alone with your opinion. I suspect that attitude is a big part of why this is such a problem nowadays.
> 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 their spotty 4G signal the SPA pattern is of no help. Not everyone is sitting still on great WiFi. Someone's cellular reception can go from great to unusable just walking down the street.
>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 not, and storage is insanely cheap.
> 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.
> done correctly
Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive.
I can also assure you that when an MVC application is done correctly you can have an equally good user experience.
> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.
This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc.
I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.
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.
> 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 counts.
Sure - caching is hard (full stop - it's really hard). But I think if you actually consider most applications, there's not really much difference between an SPA rendering from cache and a server-side page that a user hasn't refreshed in a bit.
Basically - it's not going to solve all your problems, but in my experience developers really underestimate how much usage is "read only" and a cache works fine.
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, or like and enthusiastic web users get evicted between loads. And then don’t convert because your site is “always slow”.
P95 statistics don’t tell you if 5% of your users are having a bad experience. Or if new users are massively over represented in the P95 time. You are flying blind and shouting for other people to follow you.
5 replies →
> 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 in the background. So it's similar to what you describe, but with server-rendered content.
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)
> You can cache rendered views
Sort of. There's been no shortage of vulnerabilities where user data has been exposed when an authenticated users request was cached and re-used for subsequent users. It's been my experience that most SSR apps disable caching for authenticated users, or rely on more explicit control of components for partial caching where possible.
Preloading is a browser-native feature, you don't need a SPA for that. And just as often you can't know in advance what data will be requested by the user.
> And just as often you can't know in advance what data will be requested by the user.
This is a cop-out. Storage is insanely cheap, and abundantly available on most machines. Plus the browsers will usually give it to you.
Can I know precisely what series of pages this user might hit? Nope. Can I load ALL the data this user might need to read? Probably.
Storage is cheap but bandwidth is not guaranteed. Getting content from your server to my device is not necessarily fast. Making wrong assumptions about my device's environment makes for a poor experience for me.
2 replies →
> Can I load ALL the data this user might need to read? Probably.
You can do that with HTTP/2 server push on a multi-page app, too. The main difference is that with an SPA, you get to reinvent it all yourself.
1 reply →