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.
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.
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.
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.
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
Equivalent tools for REST and non-REST HTTP do exist, but none that I've seen has been as cohesive as for instance Apollo. I used it on a small side project and was amazed at how much time and effort it saved me. The alternatives are a patchwork of different tools with slightly different goals for things like client code generation, documentation generation, playgrounds, HATEOAS, etc. that have to each be evaluated and shoehorned in with the others.
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.)
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.
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.
How is that any different from SSR? Waiting for a full page reload is fine, but incremental loading is not?
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.
If that's your targeted usecase, send an exe on a thumb drive, and get them to call you back over the phone
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.
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.
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.
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.
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.
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.
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.
But yes - I explicitly handle offline-only use cases, and god-damned terrible connections (think <1kb/s). In these situations, users are going to wait a long time for the first load either way.
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.
If you handle offline up front - you mostly get bad connection speed wins by default.
It also helps that our app really isn't intended for casual use - ex: we have very few users who just load a page or two and then leave. Mostly they'll be interacting with the page for a duration of between 30 minutes and 2 hours (sometimes as often as once a second).
So yes - very much not a "blog" or "news" or "social media" site, and I think the value proposition for most companies might be harder to sell.
But I personally find it very, very nifty that we can do this at all in a browser. 10 years ago it would have required an installed application, or a port to each mobile platform. Which is sadly still a hard sell in some of the particularly poor school districts we worked with (mostly computers from the early 2000s, if you're lucky a really cheap tablet - like a kindle - floating around)
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.
That's not what the article was about (it was very clearly advocating for the standard browser flow)
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.
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.
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".
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.
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)
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 progressively with appropriate loading indicators. For SPAs that have ~long sessions, it's arguably a good thing to have multiple API calls, because each can be cached individually: the fastest API call is the one you've already cached the response for. This is stuff we were doing at Mozilla in 2012, it's nothing new.
There's also nothing stopping you from making purpose-built endpoints that return all the information you need, too. Your proposed solution (SSR) is literally just that, but it returns HTML instead of structured data.
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)
1. get html from server (1 roundtrip)
2. get resources from server (1 roundtrip)
So to match traditional webpage total load time you cannot do any ajax calls in your SPA until after the first user action. And even then, you only match traditional website performance, you don't exceed it.
Time until the first thing is on screen however, is faster in SPA's. So it's easy to present "a faster website" in management/client meetings, despite the SPA version actually being slower.
You can make SPAs faster than traditional websites ... but, for example, you cannot use javascript build tools. Since you need to do the first calls server-side and have javascript process them, and only send the result of the preprocessing, and the resulting dom to the client, after optimization and compression. After that you need to then do image inlining, style inlining, etc. I know react can do it, but does anyone other than facebook actually do that?
This is literally a core use case of GraphQL. But you probably also want to fan out to preload all of the other user data in one API call: that's the whole point of doing it on the client. If you are trimming the handful of kilobytes on the first request, you're paying the price for that on each subsequent load.
> I know react can do it, but does anyone other than facebook actually do that?
Yes. Every job I've worked at professionally since 2016 (when this became mainstream) has done this. I do it in my side hustle. It's really not that hard.
> 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)
This doesn't go away with traditional sites.
Can you link to a tutorial for this? I'd be most interested.
I think your point is still correct. SPA by default are a huge regression and you have to build and maintain sophisticated web infra to reclaim it.
Blog or corporate/news website on one end and an interactive game or video editor in the other, with a site like FB somewhere in the middle.
It’s not a hard rule and I can already think of counter-examples but this line of thinking is useful when architecting a new project.
https://www.ireadthisweek.com/author/ireadthisweek/post/2022...
The TLDR is it takes longer than reported.
A webapp where state can exist in various components is a perfect fit for SPA-s. Clicking a button in a widget and submitting the page with every other state, updating them and refreshing the page makes no sense.
SPA-s also help with separating frontend and backend development, they are different beasts. I know many backend devs who wouldn't touch frontend with a 10m pole and not because of JavaScript, but because they don't like design and UX in general.
These people have lives and other shit to do besides spend all day in my web app. There’s a lot more accidental and exploratory clicks than you think and all of the background requests run even though the user is only on that page for half a second.
But not every AJAX request is blocking or necessary for the site to be usable.
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 a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.