Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> 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 a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.

View on HN

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.

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.

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.

It's still a specialty sub-discipline though. Getting the base size down is a wonderful goal for a framework. But for the behavior the company is adding, there are both diminishing returns and a lot of surface area for bugs.

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 <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.

Your application seems to be a magical unicorn (not being sarcastic!). Most SPA websites I use on a regular basis end up having to reload all of their page components every visit, and frequently on every 'back'.

I'll be really honest here - it helps that it was a direct requirement from day one, and we have financial incentives aligned with handling the offline-only case.

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)

> 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.

> 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)

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".

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.

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.

> have to click 5 or buttons/menus and then wait for data to load, then click again, and more data.

How is that any different from SSR? Waiting for a full page reload is fine, but incremental loading is not?

Worse yet, with a traditional web app, you are in control of loading the page - or stopping the load, for that matter. With an SPA, it does all those requests in the background. Many apps fail silently (as in, don't refresh) if request to the backend fails.

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.

It doesn't happen by accident in the same way that preventing an SQL SELECT N+1 problem doesn't happen by accident. Poorly written software is poorly written.

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.

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.)

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.

> 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.

> Still doesn't make an SPA the right fit for everything

It's still worth pointing out.

I would counter that data freshness and authZ concerns make SPAs a poor fit for most things. What you're proposing in this thread is that good SPAs essentially need to hold all data client side and not have to worry about out of band cache invalidation, which seems like a pretty rare set of circumstances.

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.

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.

> 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.

> 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.

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

Yes, I obviously mean leverage the existing tools, not roll my own implementation of the protocol, that would just be stupid and counter-productive.

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'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.

> 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.

> 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.

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.

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does).

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)

Vs traditional:

    1. get html from server (1 roundtrip)

    2. get resources from server (1 roundtrip)

Also if there are sequential ajax calls required to build the page (like a list -> detail view), it goes up a lot without speed oriented (very bad code style) API design. For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.

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?

You eliminate #3 by having data preloaders inline it into the html response and move it into #1. But without SSR your rendering still starts after #2 instead of #1.

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.

Yes, but most of the time (getting the HTML and all the Javascript etc) is only at startup time. Let it take a second or two. From then on the user is in the application, and everything is much faster than it used to be with getting entire new pages from a backend every other click.

I wrote a post very similar to this comment that you might be interested in reading. I broke down what takes time to load, how fast the browser determines something has loaded, and how fast the user can perceive the page loading. I ended up having to take a high speed video and measure frame by frame the time it took to load for user perception.

https://www.ireadthisweek.com/author/ireadthisweek/post/2022...

The TLDR is it takes longer than reported.

The more something behaves like an actual application and the higher the number of user interactions per visit, the more sense the SPA approach makes IMO. This is because the initial load overhead of an SPA gets amortized over subsequent interactions.

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.

> For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.

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.

> 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.

Can you link to a tutorial for this? I'd be most interested.

SSR isn't a one-size-fits-all solution. Blogs? Sure. Corporate marketing site? Absolutely. Wikipedia? What else.

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.

People generally have a very bad estimate of just how engaged users are with their sites.

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.

> Every AJAX request is an extra roundtrip

But not every AJAX request is blocking or necessary for the site to be usable.

If you can do it in a single GET/POST in an SSR, you can do it in a single XHR call in an SPA. There's no reason it has to be split up in separate XHR calls.

You just have to want to do it.

Reply on news.ycombinator.com