Hacker News Reader

> But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages.

I often work on a train over a 4G connection, so this describes me too. I much prefer traditional style web applications over SPAs specifically because of this.

You know what happens if a request is taking too long or fails with a traditional web app? I hit reload and it retries.

You know what happens if the same thing happens with most SPAs? It throws away my unsaved data and puts me back on the starting screen.

Sometimes there's a JavaScript-powered retry I can use instead. Sometimes it works, usually it is very unreliable (if something has failed to load, often the JavaScript is having problems too).

Sure, I'm willing to accept the possibility that an SPA can be written in such a manner as to compensate for this hostile environment. It's just: I've used a lot of these apps, and I haven't found one that works reliably over a poor connection yet.

> You know what happens if the same thing happens with most SPAs? It throws away my unsaved data and puts me back on the starting screen.

This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, basic error handling, and always have the URL represent where the user is.

>This is just bad design though. Obviously the dust isn't settled on the whole html5 technology yet, but for anyone who is wondering how to make an SPA more resilient to network instability, the solutions are: axios-retry, idempoteny PATCH/PUT, service workers, and basic error handling.

Thing is, you get proper error messages, the ability to retry, warnings if you're about to repeat an unsafe operation etc out of the box if you don't use a SPA and render things server-side. The browser does this for you.

Sure, you can do a better job. But I've lost count of the number of SPAs and JS-driven apps where connection error = infinite spinning loader icon and no feedback or ability to retry. If you're going to willingly throw away the routing you get from HTTP, the progress indicators you get from actual links and non-AJAX requests and the browser error handling you better make damn sure you implement it all again in JS and provide feature parity for the user.

It's not just HTTP either - accessibility features like keyboard navigation often aren't implemented in React components because folks only write an `onClick` handler. Sure - the devs should've loaded "eslint-plugin-jsx-a11y " and enforced rules that prevent this sloppiness on their CI - but it's far too easy to do it wrong and so devs do do it wrong and the users suffer from a poor experience as a result.

I've seen pure server based applications neglect all of those things, including destroying your input on errors, so it's not really helpful for anyone who actually needs an SPA.

Yep, how many times have you seen a web page say tell you not to refresh the page to avoid losing your progress.

so many older job applying application tend to be built in this way. Its happened way too often that I have filled in a whole page of info, from my birth to every job I have ( even though I literally have a resume just for that ), the browser crashes and I lose everything.

> so I still have to wait an annoyingly long time

> it drops every 10th request

If the app saves data to a server, that's gonna happen regardless anyways (and one could argue that techniques like optimistic updates might make the experience even worse)

Also remember that HTML can be streamed and partially rendered even if it's not fully downloaded, and the investment required to enable this is minimal. The same cannot be said about a SPA's data fetching/rendering strategies.

Having worked on bloated apps before, I despise when people throw around the word "prefetching" as if it's some sort of magic spell. At best it eats my battery and bandwidth needlessly, and at worst, it's weasel wording for slowing down time-to-first-pixel :(

I keep hearing offline-first trumpeted, but I have seen no examples of what that means.

Terrible connections exist. But I fail to see how adding more scripting will always help with that. Service workers are definitely promising, but documentation for common use cases is still lacking.

Even with a terrible connection, I would still trust a server-side app to load correctly on a refresh more than a SPA.

If anything, the minimal use of Javascript is as inclusive as a web app can be.

I think they're talking about mobile twitter, where every time I visit I see the message "something went wrong". Then I tap retry and get the same message. It's very offline first. Then I reload the whole page and get the online version.

It seems to have to do with blocking their trackers: https://news.ycombinator.com/item?id=19130667

> But I fail to see how adding more scripting will always help with that

Your app has no control over browser connection management. JavaScript you write is aware of idempotency and retry semantics of your app, so it can manage requests more intelligently than the browser, without disrupting the user experience.

So sure, it won't always help if you do it badly, I can see how it always helps if you do it well.

Henrik Joreteg (https://twitter.com/HenrikJoreteg) makes some pretty good arguments for PWAs. I've not had the chance to work on one, but when you start looking at mobile devices in particular, they do seem to be a good middle ground between the slimness of a document (web page) and the capability of a native mobile app. They're also not mutually exclusive with "no javascript" (if you do it right, which is a consideration). And they have the potential to save developers work, since you can get away with a PWA instead of native apps on 2+ platforms.

I'm very much on board with the promise of PWAs, but so far I've never found an approach that didn't feel too complicated/tedious. That said, I've not made serious attempts in at least a few months, maybe a year. Would you say the situation has solidified/standardized in the interim, and if so, could you point me to some resources?

Unfortunately, I'm in the same boat, having only fiddled briefly with some of the newer web APIs, rather than architecting an app around service workers. My impression comes from folks like Joreteg who do the work, and from the increasing frequency with which new native-like APIs are released into browsers (though almost invariably implemented badly).

That said, even though the way service workers are registered is sort of odd, they're pretty trivial to work with once you're there. As far as resources go, MDN is always pretty solid, and this post (https://developers.google.com/web/fundamentals/primers/servi...) on Google's web dev guides is what I used to familiarize myself with them.

The neat thing is, an app using Service Workers doesn't have to be an SPA. You can use a Service Worker to just cache HTML as delivered from your server. E.g. I've seen blogs having a small service worker that just cached the last 5-10 accessed articles and added a custom error page saying "sorry, you are not online right now, but you can read the following articles from cache:"

It’s great that you have an opinion about the benefits of a SPA for slow connections and other people (lower comments on this thread) have opinions about how “easy” it is to implement request retries and caching/service workers.

I have an opinion too. But my opinion and your opinion really are moot.

Because do you know whose opinion is probably backed by the most data and the most expertise? Google’s Gmail team.

And Google, with all its amazing developers, who are arguably at the forefront of javascript standards and general web app innovation, and who have literal billions of visits, they have made the decision to give you a link and tells you to use a basic, server-side rendered web app if you have a “slow connection.” And they do this while attempting to boot up all the PWA/SPA framing of the main app, just in case, I don’t know, all that stuff fails.

So I think I’m going to give Gmails opinion a lot of weight here

Gmail's slow connection message is great, but it's there because Gmail is a multi-megabyte app that will take a long time to download if you're on dial up or something. That's a bandwidth issue rather than latency or line quality problem. None of the points I made say anything about bandwidth.

I completely agree with the point you're making though; if a user is on a low bandwidth connection then sending as little data as possible is best, and that's likely to be plain HTML with very little rich content like images.

That said, Gmail's slow connection UI is horrible to actually use. Very few people choose it over normal Gmail. Most people want the big fancy app, so we as developers should work out the best way to deliver that.

Did you try using the site with the inspector open with Poor 2G throttling? I was still able to interact with the page within milliseconds. Just had to wait for the font to download before text would appear. Then after that, all of the assets besides the HTML was cached.

I think that's pretty damn good; to solve the 2 second latency, I think the developer is better off using a CDN or Netlify's ADN so that your site is delivered from a server closer to the user.

> If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better.

This is a unicorn. If it's the real world we're talking about, as far as I can tell client-heavy webapps that are actually engineered this well -- and don't frequently end up in a more inscrutable state than a pageload failure when network issues rear up -- are rare enough in practice that it feels weird to hold that up as the yardstick for criticism.

And if the point is that more applications should get there, well, that's more or less orthogonal to the point of the article, which (in spite of the headline) isn't so much that no one should use JS for anything ever (since the author details the JS he made a thoughtful choice to include), but that a notable range of UI behaviors that are frequently implemented using JS without a second thought don't necessarily have to be, and there are plausible benefits to the alternative. So this isn't exclusive with background loading / prefetching.

Agree that an offline-first PWA is the way to go. Not _no_ javascript, just _as little as possible_. However, I've also not seen such a good example before of how doable this is, so thanks to the author for the show-and-tell. The label/checkbox example is a new one on me, and covers pretty near 80% of my use of javascript. It's interesting how when you strip html of all the DOM api nonsense it starts to look like an exciting new framework. Forms are such a nice, declarative way to get user input.

It's also possible to cache server-rendered pages offline with a service worker. Admittedly not many people do this, but there's no reason why they couldn't, and it would probably be smaller for a lot of sites.

Prefetching is going to waste data in a lot of the world where you pay by the megabyte.

Everything is a tradeoff.

You prefetch what is required, and cache what is requested.

Assuming you aren't one of the sites that thinks it's appropriate to require `DOOM.WAD`, it can work out well.

> it drops every 10th request

Who has good heuristics for retry (or other techniques) to achieve reliable communications for a PWA?

We do retries, with a few different strategies, but we have a poor idea of exactly how effective (or not) our retries are. Also my code for this is ugly and it's a nasty area to test properly...

> If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better.

Then I would have waited too long to load the page the first time and give up.

The code you received the first time you load the app should be identical to the server-rendered version with a single additional script tag that loads a small JS file asynchronously. That script then progressively enhances the page to make it a PWA with features that take advantage what your browser supports.

Not enough developers build this way yet though because it's quite hard work. In my opinion the answer is to use what browsers are capable of; it should not be to ignore the browser and do as much as possible on the server.