Comment by zozbot234
4 years ago
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.
4 years ago
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.
if you cache well - you will absolutely use less bandwidth with an SPA.
Sure - that first load is going to be bigger, but literally every subsequent request will use less data.
I try to reward consistent and current customers - and I'm not selling a news article or a social media site...
Now - if you do things like attempt to refresh all of the cache often, then sure, you have some problems to deal with.
> Making wrong assumptions about my device's environment makes for a poor experience for me.
Tough shit? I go way out of my way to make sure that loads on bad lines (or no lines) don't interfere with my users. You could just as easily say "I'm on gigabit why is this app using my disk space? Making assumptions makes for a poor experience. WAAAH".
1 reply →
> 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.
Yeah - there's a trade off here.
Server push gets you closer with a traditional app, but it doesn't really solve the problem (or rather - yes, you get to reinvent it yourself, but you can do it better, with the specific context of your app)
Basically - My argument is that developers tend to treat SPAs the same as "the website" but with a bigger js framework. And that's the wrong mindset.
Instead, you should think of the first load as an install of a native application. You want to push absolutely everything, not just the next couple of resources you might need (like imgs/css). Ideally you push the current page first, and do the rest in the background while the user can interact with the current page, since you're almost never CPU bound on terrible connections anyways.
You'll get one additional load at login (because now I'm pushing all relevant user data), but after that... basically everything is rendered from cache (including optimistic cache updates based on what the user might be adding/updating).
After that... unless you log out or have cache evicted, you're going to see immediate response times, even while offline.
---
This isn't easy, and most teams don't bother, so if the comment is "If you're treating an SPA like a traditional page - don't bother" then I tend to agree.
but an SPA genuinely opens up options for bad connections that otherwise just don't exist (or are so bad people won't use them)