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

51–60 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#51

Post by thenipper »

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…

That feedback that the commands are queued or can't be processed is key. I encountered an issue on an app I manage at work where the UI showed that a certain state changing action had taken place before it was resolved on the sever. Needless to say it caused a variety of issues as users thought the system had processed a significant action(hiring a candidate) when they hadn't.

Re: Offline First – A Better HTML5 User Experience

#52

Post by Pxtl »

yonkshi wrote: post #22
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…

Having recently built an offline first app (mobile app I'll admit), we didn't use a command queue, and I regret it deeply now. I advise everyone who's reading this to go for a command queue. Saves a lot of time debugging data sync. Our biggest challenge was to sync data with relationships, especially data with circular relationships. We couldn't come up with a generic way to sync circular relationships, so we ended u…

What was the challenge with circular relationships? I work on an offline-first system and all inter-object relationships are managed by GUIDs, so cyclical references don't present any problems - objects are sent and received as one big list keyed by guids, not as a tree.

Re: Offline First – A Better HTML5 User Experience

#54

Post by freditup »

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…

What about in cases where the commands may fail because of the actions of other users? For example, say you had a virtual market in a game and someone did a "buy from John" command while offline. they then proceed to use this purchase to beat future levels. However, once the user reconnects online, it turns out that John already sold to somebody else, and thus their purchase and everything after it is invalidated.

In your command queue pattern, what sort of ways do you handle this? Have certain "chokepoints" where the user must be online to proceed? What if you have an app where that sort of chokepoint seems to occur too frequently to make the queue useful?

Edit: I think this is similar to Fiahil's sibling comment, also relevant points made there. Thanks for the quality thoughts everyone!

Re: Offline First – A Better HTML5 User Experience

#55

Post by JustSomeNobody »

niftich wrote: post #9
tannhaeuser wrote: post #2

Isn't it simpler though to just use static HTML + optional Javascript (like we used to in the 2000's eg. progressive enhancement years)? I mean why use M-V-whatever for content-driven sites at all?

(2012) The article is older but the advice is sound: only reach out to the server when you need to and ensure your client-side state doesn't break when you can't. It's a little strange that they avoided naming any JS MV* frameworks even though some where out by then -- Backbone, Knockout, Ember, Angular, if I recall. But this article makes the point that all future JS MV* development went on to consider best practice…

Why is it strange? If one starts naming frameworks, one's blog post would be outdated by the next week.

- only slightly sarcastic.

Re: Offline First – A Better HTML5 User Experience

#56

Post by cryptarch »

How about offering a HTML experience in the first place?

I'm really tired of "HTML" websites that are actually a heap of Javascript writing to a virtual DOM, with only a few references to scripts, most of it being for surveillance (e.g. ad trackers, surveillance for profit with the side effect of it being available to intelligence services via subpoenas, gag orders and secret courts).

Re: Offline First – A Better HTML5 User Experience

#57

Post by c-smile »

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 storage/caching approach. "Offline first" is too broad.

Re: Offline First – A Better HTML5 User Experience

#58

Post by JoelMcCracken »

freditup wrote: post #54
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…

What about in cases where the commands may fail because of the actions of other users? For example, say you had a virtual market in a game and someone did a "buy from John" command while offline. they then proceed to use this purchase to beat future levels. However, once the user reconnects online, it turns out that John already sold to somebody else, and thus their purchase and everything after it is invalidated. In…

The real thing is, it is important to synchronize with the server at that point, otherwise something could be invalid.

It may not be possible to make every app work while offline. You'll probably want to potentially disable certain features while offline, such as store purchases (or, at least, queue them up, but don't show them as having been successfully purchased)

Re: Offline First – A Better HTML5 User Experience

#59

Post by ramzyo »

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…

This makes so much sense. Would have saved me many headaches when developing an offline app a few years ago.

Re: Offline First – A Better HTML5 User Experience

#60

Post by smackmybishop »

freditup wrote: post #54
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…

What about in cases where the commands may fail because of the actions of other users? For example, say you had a virtual market in a game and someone did a "buy from John" command while offline. they then proceed to use this purchase to beat future levels. However, once the user reconnects online, it turns out that John already sold to somebody else, and thus their purchase and everything after it is invalidated. In…

That case would probably need server synchronization to confirm, but other cases can be handled with operational transformations.

https://en.wikipedia.org/wiki/Operational_transformation

Post reply on HN