UpUp: a tiny script that makes sure your site is always there for your users(talater.com)
talater.com
UpUp: a tiny script that makes sure your site is always there for your users
https://www.talater.com/upup/
3 comments
By HTML5 manifest file, do you mean the Application Cache? Because that is apparently (I've never tried it) anything but an 'easy way' [0]. Whereas this script appears to wrap ServiceWorkers, which is the 'modern', recommended way to do things [1]. Also being a 'neat wrapper' with a simple API is often a good enough reason for something to exist.
[0] http://alistapart.com/article/application-cache-is-a-doucheb...
[1] https://www.youtube.com/watch?v=SdMxGNkZqnU
[0] http://alistapart.com/article/application-cache-is-a-doucheb...
[1] https://www.youtube.com/watch?v=SdMxGNkZqnU
[deleted]
Oh wait. The description makes it look like you can server your pages even when YOUR SERVERS are offline.
But in fact, this script just saves stuff somwhere on the client, so the client can see certain things even when THEY ARE offline.
Maybe I was the only one being this mislead.
Just, when I am a client and don't have internet, then I don't have the idea to still browse the internet. So what are the ultimate goals for this "offline first movement"?
But in fact, this script just saves stuff somwhere on the client, so the client can see certain things even when THEY ARE offline.
Maybe I was the only one being this mislead.
Just, when I am a client and don't have internet, then I don't have the idea to still browse the internet. So what are the ultimate goals for this "offline first movement"?
This will also work when the site's servers are down. It serves offline content from the local cache if the original fetch fails - it can fail either due to your device's connection, the server, or anything in between.
However, since offline content is served after trying the network, it's still going to be slow in flakey network conditions as you wait for the original request to either succeed or give up.
However, since offline content is served after trying the network, it's still going to be slow in flakey network conditions as you wait for the original request to either succeed or give up.
The use case just from the demo on the first page looks reasonable: you're on an airplane (or a train or in a car far from civilization) and you want to look at your travel itinerary/hotel's address/see the check-in time. Granted, it's pretty narrow, but not out of the realm of possibility.
I can see one use case I sometimes encounter - that I return to an older tab in my mobile browser, but because I'm currently offline, or in 2G area, I don't see anything for a minute or more.
Don't get me wrong, it's a really neat wrapper, I'm just curious about why I should use this library instead of an already in HTML5 implemented, easy way which does pretty much the same?