Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Offline First – A Better HTML5 User Experience

joelambert.co.uk

Post reply on HN
Print view View original

81–90 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#81

Post by mbrock »

brilliantcode wrote: post #45
mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

Do you mean like CQRS/ES?

It makes a lot of sense in an event sourcing context because the code used for applying events can be the same in the optimistic case and in the real updates.

In our case, we weren't using an event sourcing architecture, but this client side pattern can be used anyway.

Re: Offline First – A Better HTML5 User Experience

#82

Post by RandomInteger4 »

afarrell wrote: post #4

Doesn't Chome on iOS prevent this because it reloads whenever you re-open a page, even if you don't have an internet connection?

I think there is a flag under chrome://flags where you can turn off automatic page reloading if the system is disconnected from the internet.

That being said, doesn't appcache provide the offline page if the browser can't connect?

Re: Offline First – A Better HTML5 User Experience

#83

Post by Klathmon »

CorvusCrypto wrote: post #35
CardenB wrote: post #14

Earlier quoted context omitted.

Aren't there lots of caveats for each platform when using so called "cross-platform" code?

yes. There can be a lot of boilerplate code present, however in terms of speed, using Qt for instance, can be much faster still than a web application that accomplishes the same task even if you get a huge binary after compilation. Oh and as Nadya said, sometimes this generalization causes issues. Engineering is a game of trade-offs I think :P.

What's the speed of the install process for those apps?

How's the update system work?

How quickly can you release them to all platforms?

Can they be easily customized and modified by the user?

Can they be easily shared?

What's the permissions model like? How much can that application access?

Re: Offline First – A Better HTML5 User Experience

#84

Post by JustSomeNobody »

AgentME wrote: post #64
ksk wrote: post #24

Earlier quoted context omitted.

They do, but they're convinced that asking people to install software is verboten.

Smart users don't like installing every little thing they want to try and giving them all full unsandboxed access to their computer. On the desktop, the easiest way to run an app in a sandbox is if it's a web app that runs in the browser's sandbox to begin with.

Depends. On Windows? Sure, I freaking hate installing software on Windows. On Mac or Linux? Meh, not an issue for me.

Re: Offline First – A Better HTML5 User Experience

#85

Post by mbrock »

wnevets wrote: post #44
mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

Know of any good examples/tutorials of this?

Unfortunately not, but if you think of it as using the command pattern in a queue-ish way to get a similar behavior as the command queue of "The Sims", you have the basic architecture, and from there it's just a matter of coding.

The thing about React-like frameworks that makes it very nice is that you can keep the command queue in a separate place and have a root rendering function like this:

1. Set the view state to a copy of the actual state

2. Update the view state according to each queued command in turn

3. Render the view state including a status bubble showing that some changes are not saved yet

And separately from the rendering, you have a worker that tries (and retries) to perform the queued commands. When a command is successfully performed, it's removed from the queue and its effect on the state is saved in the actual state.

Since I can't find anything on Google when searching for "react command queue" it would be cool to write a blog post with a simple example, but I don't know when I'd have time, so I encourage anyone who's implemented a similar thing to go ahead.

Re: Offline First – A Better HTML5 User Experience

#86

Post by mbrock »

ksk wrote: post #75
AgentME wrote: post #64

Earlier quoted context omitted.

Smart users don't like installing every little thing they want to try and giving them all full unsandboxed access to their computer. On the desktop, the easiest way to run an app in a sandbox is if it's a web app that runs in the browser's sandbox to begin with.

As long as we're trending towards web-apps having native apps' functionality then that distinction will soon be meaningless. Native apps are already sandboxed in various ways. Process integrity levels, VM protection, low privileged execution, call gating, ACLs, MAC, etc etc. All these technologies already exist and are already being used in various ways. Any systems level programmer should already be aware of those.…

Unless you're running a very unusual OS setup, any native app by default has read and write access to all of your files without asking.

I feel pretty comfortable assuming that www.randomwebapp.com isn't reading and uploading my ~/.ssh and ~/.gpg, otherwise I'd be terrified of using the web at all.

Re: Offline First – A Better HTML5 User Experience

#87

Post by mbrock »

ebbv wrote: post #69
jedberg wrote: post #66

Earlier quoted context omitted.

All mobile apps will be offline at some point. Cell coverage doesn't cover 100% of the planet yet. The question is, how good of an experience will you be able to deliver when your client is inevitably in one of these places?

Of course but if you're writing a web app who's only purpose, for example, is to talk to support staff for your company then having an offline mode is not really useful. If you're offline you can't talk to the staff, so all the app needs to do is fail gracefully. Designing it "offline first" would be silly. I actually believe that >50% of web apps probably fall into this category, where they really cannot function pr…

Offline first basically means that if you send a message while your network is temporarily down, it's just queued and resent immediately once the link is up again, like your email outbox.

Since network links are always flaky, it just makes sense to do it this way. Since they are also always relatively slow, it makes sense to cache data locally in order to give a faster experience.

Not doing things offline-first in an app basically means that you are introducing synchronous requests everywhere: reading a support reply from yesterday is a synchronous request that fails "gracefully" if your 3G happens to be down, etc.

Telegram's web app is pretty nice. The app code is cached offline with a service worker and updated whenever possible, so it loads instantly. The most recent messages from your contacts are saved in the client as well. I appreciate all that stuff as a user, and the more stuff works offline the better, because it also means it's faster and more reliable.

For more info:

http://alistapart.com/article/offline-first

https://developer.chrome.com/apps/offline_apps

Re: Offline First – A Better HTML5 User Experience

#88

Post by greenyouse »

c-smile wrote: post #57

Wearing my architect cap... There are four types of applications in that respect: 1. always disconnected (e.g. calculator) 2. occasionally connected (e.g. email client) 3. occasionally disconnected (e.g. messaging client) 4. always connected (e.g. trading terminal) First architectural task I am doing when have given an application idea is its classification using these models. Each particular case requires its own st…

There are a few more patterns as well if you use ServiceWorkers. Jake Archibald has a great "offline cookbook" article that lays out other common use cases and strategies.

[0]https://jakearchibald.com/2014/offline-cookbook/

Re: Offline First – A Better HTML5 User Experience

#89

Post by junaidajmal »

mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

Stay at home mom Kelly Richards from New York after resigning from her full time job managed to average from $6000-$8000 a month from freelancing at home… This is how she done

,,,,,,,,,,,,,,,HERE ►WWW.bizcash3.COM

Re: Offline First – A Better HTML5 User Experience

#90

Post by junaidajmal »

Fiahil wrote: post #63
mbrock wrote: post #18

The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…

You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's not a matter of pushing clients' commands anymore. Instead you have to merge changes (either backend or front end side) before fetching the new state. For example, I try to purchase an item on my desktop, but can't because I lost connectivity. So, I proceed to b…

Stay at home mom Kelly Richards from New York after resigning from her full time job managed to average from $6000-$8000 a month from freelancing at home… This is how she done

,,,,,,,,,,,,,,,HERE ►WWW.bizcash3.COM

Post reply on HN