Hacker News Reader

Comment by freedomben | Hacker News Reader

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.

View on HN

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.

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

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.

It's still worth pointing out.

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com