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

121–130 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#121

Post by CorvusCrypto »

allannienhuis wrote: post #72
Pxtl wrote: post #52

Earlier quoted context omitted.

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.

"objects are sent and received as one big list keyed by guids, not as a tree" That's an interesting pattern I've not heard of before - any links you could recommend for more details on it? It sounds really useful for moderate sized data sets.

didn't Netflix do a bunch of research into json-graph? They seemed to have figured this problem out.

Re: Offline First – A Better HTML5 User Experience

#122

Post by krick »

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…

I'm not sure I get what you mean by "always connected". Because speaking about how stuff should be written, I would expect developer never goes farther in his assumptions than #3. That is, I would hope my trading terminal still works just fine after the whole office goes offline for 10 seconds (or more, doesn't really matter). Actually, I would care quite a bit more about my trading terminal handling such cases, than, say, messaging client.

Re: Offline First – A Better HTML5 User Experience

#123

Post by pkaeding »

coldtea wrote: post #114
pkaeding wrote: post #112

Earlier quoted context omitted.

JSON-Patch [1] can be helpful here. You can maintain a list of changes that need to be applied, such that they only touch the parts of the document that need to change (other changes to other parts can be interleaved). If necessary, you can include tests to assert that some value in the document is what you expect it should be, and the patch can be rejected if that test fails. [1]: http://jsonpatch.com/

That's if what's to be changed is a document (which is a big if). Things get ugly quickly for any more complicated scenario.

Yeah, that's true. JSON-patch won't help with all situations. It is still an under-utilized tool, IMO.

Re: Offline First – A Better HTML5 User Experience

#125

Post by c-smile »

krick wrote: post #122
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…

I'm not sure I get what you mean by "always connected". Because speaking about how stuff should be written, I would expect developer never goes farther in his assumptions than #3. That is, I would hope my trading terminal still works just fine after the whole office goes offline for 10 seconds (or more, doesn't really matter). Actually, I would care quite a bit more about my trading terminal handling such cases, than…

At the age of electronic trading that 10 seconds off-time of your trading terminal makes it almost useless.

Re: Offline First – A Better HTML5 User Experience

#126

Post by c-smile »

DougBTX wrote: post #110
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…

Thanks, that's a nice breakdown. I suppose some apps will be combinations, e.g. Wolfram Alpha can do simple sums entirely offline, while the more complex stuff is entirely online.

Yes. Yet some applications even have different connectivity models for different modules. Reality is as usual is not that black and white. Truism of course but still.

Re: Offline First – A Better HTML5 User Experience

#127

Post by raquo »

amelius wrote: post #117
andrewstuart2 wrote: post #107

Earlier quoted context omitted.

Conflicts are actually not all that difficult to solve. We had to solve this exact problem with a time entry solution that needed to be mostly available offline. Taking most of our inspiration from Git, it was simple. Define the atomic unit of conflict, and the definition of a conflict that cannot be automatically resolved, and simply help the end user understand and resolve the conflict. 95% of cases were fairly eas…

The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.

I've once built a system (an outliner app) that actually encodes intent, and uses a command queue ("transaction queue").

Intent could be for example to insert this new item as a first child of that other one, or to move these items to a position right before some other item, or to set font size on this item to 4.

The data structure was a tree of item objects linked via next/prev/children/parent. Automatic conflict resolution works wonderfully in this case.

Re: Offline First – A Better HTML5 User Experience

#128

Post by Klathmon »

CorvusCrypto wrote: post #119
Klathmon wrote: post #83

Earlier quoted context omitted.

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?

One thing I have noticed in this thread in general is that the web devs are extremely defensive. No, a web app is not inherently bad. No one is saying this. But cherry picking questions to prove a point is silly. However, to show it's not a gangup on web apps here we go: Speed of the install process? Probably slower than loading a web page for serious applications How does the update system work? Depends if you're re…

And one thing i've noticed is that "native devs" are extremely condescending.

I hear a LOT about how writing an application for the web is wrong (especially on HN), but not much about why it's a good idea. I see comments about how native is faster, "less bloated", portable, "better designed", offline, and more secure. But never any comments on how long they take to install, how difficult it is to use them across multiple devices, how you need to either use an app-store, bundle your own updater (which follows all the best security practices), or rely on a distro to get around to including it for you. I never read discussions on how they tend to be larger, they have more access to the underlying system by default, how they are more difficult to secure, or how if you use the one application across multiple platforms you need to learn multiple UIs.

And while none of that is true across the board, it's stuff you need to spend more time on to get right, whereas you tend to get it "for free" when targeting the web. Obviously things go the other way for some features. Getting high performance out of a web app takes more work, getting "high security" to work in a browser is much more difficult, getting offline takes some consideration (IMO it's not that difficult today, but it does still take work).

It might come across as defensive, but I can't bring up anything web-related on this site without being asked why I didn't make it native, or why I'm using javascript at all, or why I decided to use the web when there are "perfectly good UI toolkits for native app development" while hand waving away all the benefits and reasoning behind my decisions as either pointless or just by saying "you can do that with native too" without going into the mountain of work necessary to get it right. And in that comment I indulged that anger which I don't normally do on this site.

Re: Offline First – A Better HTML5 User Experience

#129

Post by mjevans »

sgk284 wrote: post #74
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…

I'm a big fan of command queues, but if there is a chance of a server-side failure that can't be realized immediately on the client (e.g. an edit conflict with a different user editing a same piece of information), then I find that surfacing those errors in a meaningful way can be difficult and frustrating for the user. By the time the client has synced with the server, the client could be doing something completely…

Treating changes more like emails/outgoing order forms might be useful here.

You could popup a /failure/ message and leave a little indicator icon that takes them to the queue and lets them see the items that failed. If retry is an option they can see it, if retry is not an option they can be told why.

Post reply on HN