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

111–120 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#111

Post by ksk »

mbrock wrote: post #95
ksk wrote: post #93

Earlier quoted context omitted.

>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. That's partially true. By default, it cannot access any system files, or change any system settings without admin privileges. Admin access is also required to authorize a firewall exception if it wants to use the network. And you have the choice to arbitrarily restrict a software's…

Wait, what native app sandbox are you talking about? Any executable I run has access to my files, and that's how it works on every OS I've ever used. I am too trusting of browser security though, you're right about that...

There are tons of sandbox type features in most modern OSs to prevent apps from interfering with each other. For e.g..

1) Virtual memory protection (can't access other app's memory)

2) Protection rings (safe transfer from UM to KM for system calls)

3) User interface isolation (one process can't interact with another's UI)

4) I/O privilege levels (prevents one rogue app from causing I/O starvation)

5) Process Integrity Levels. You can run apps under your own identity (be it super user or admin or regular user) but assign them reduced permissions as far as accessing data goes. You can run at-risk apps this way so that they can run without having access to any of your data.

6) You can restrict access to various other things in addition to the data using ACLs (network, device drivers, etc).

7) ABI level isolation using user mode kernels ("Library OSs").

Re: Offline First – A Better HTML5 User Experience

#112

Post by pkaeding »

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…

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/

Re: Offline First – A Better HTML5 User Experience

#113

Post by yellowapple »

I disagree rather strongly with the implicit advice here: that HTML5 "applications" ought to rely on client-side processing first and foremost. This usually translates to "shove more Javascript down the user's throat", which is the opposite of "a better HTML5 user experience" IMO. If I trust you enough to want to run arbitrary Turing-complete code of your making, I'd be more inclined to download a native implementation for my platform; otherwise, I generally have better things for my CPU to do than burn cycles on things that should be done on your own servers.

I do agree, however, that the HTML "app" ought to be treated equivalently to native implementations -- that is, it should communicate over the same API (or perhaps an internal equivalent) as native apps. I like to think of this as "middle-end" web development, with the HTML-generating server working to mediate the browser's expectations (HTML and CSS and maybe some Javascript if it's really needed) with the actual business logic provided by the API.

Re: Offline First – A Better HTML5 User Experience

#114

Post by coldtea »

pkaeding wrote: post #112
Fiahil wrote: post #63

Earlier quoted context omitted.

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…

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.

Re: Offline First – A Better HTML5 User Experience

#115

Post by amelius »

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…

Unfortunately, the "command queue" abstraction does not work very well with access control. Imagine that one day the requirements w.r.t. security change. What do you do when some parts of the state may not be viewed by all users? And what if that logic depends on the state itself?

Re: Offline First – A Better HTML5 User Experience

#116

Post by intrasight »

jedberg wrote: post #62

These are basically the same rules for any distributed application, like something using microservices. An app is just the edge node of a distributed system. In any distributed system, the biggest cost is moving data between nodes, and therefore the biggest failure case is when data is moving slowly or not at all. It's a case you should always be prepared for. If you write your app in a way that assumes the network i…

> These are basically the same rules for any distributed application

And we've been doing those for like 50 years now. So why is this still so hard? Because new developer were, for all intents and purposes, born yesterday.

Re: Offline First – A Better HTML5 User Experience

#117

Post by amelius »

andrewstuart2 wrote: post #107
Fiahil wrote: post #63

Earlier quoted context omitted.

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…

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.

Re: Offline First – A Better HTML5 User Experience

#118

Post by amelius »

pkaeding wrote: post #112
Fiahil wrote: post #63

Earlier quoted context omitted.

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…

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/

I think it's strange that it doesn't efficiently handle patches of strings.

By the way, I'm still looking for a 3-way merge algorithm for any datatype in Javascript.

Re: Offline First – A Better HTML5 User Experience

#119

Post by CorvusCrypto »

Klathmon wrote: post #83
CorvusCrypto wrote: post #35

Earlier quoted context omitted.

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?

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 releasing as a single statically compiled program or using shared libs that can be updated. Also if you have a db to sync this will affect things.

How quickly can you release them to all platforms? As long as it takes to compile to all compatible targets.

Can they be easily customized and modified by the user? in what regard? if you mean configuration then yes. If you mean being able to manually tweak the style of the application like when fiddling around in the element inspector, then no unless you are using a theme parser that lets them adjust the themes.

Can they be easily shared? yes

What's the permission model like? Depends what granularity you want to have. Permissions can be restricted to the action level, user level, group level, machine level, global level, etc. Whatever logic you want to implement really.

How much can that application access? access in terms of what?

Re: Offline First – A Better HTML5 User Experience

#120

Post by CorvusCrypto »

kaoD wrote: post #48
CorvusCrypto wrote: post #35

Earlier quoted context omitted.

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.

> in terms of speed That's the point. Most applications don't need speed, and most that need it can offload speed-critical code with no significant drawbacks. The web is fast enough for 99% of use cases.

I agree. Was there any thought I didn't ;)?
Post reply on HN