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

141–150 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#141

Post by [deleted] »

Klathmon wrote: post #128
CorvusCrypto wrote: post #119

Earlier quoted context omitted.

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 mult…

[deleted]

Re: Offline First – A Better HTML5 User Experience

#142

Post by heisenbit »

amelius wrote: post #115
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?

I see management and security on different planes requiring parallel priority paths. Activity on these channels can be intrinsically disruptive and may require clearing queues elsewhere.

Re: Offline First – A Better HTML5 User Experience

#143

Post by Klathmon »

AlphaSite wrote: post #140
Klathmon wrote: post #128

Earlier quoted context omitted.

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 mult…

Part of the issue is that you are optimising for your own time and experience, not the users.

But I'm not.

I hear this excuse a lot, but there isn't a single benefit I've talked about which is for the developer only.

Install times are a big one. No user wants to install thing and manage dependencies or manually install updates. The sandboxing is another very pro-user thing as it makes sure my fuckups or mistakes can't easily cause their whole PC to be compromised, and they don't need to spend time making sure they have permissions setup correctly for my application on every device.

And for me, as a user, I greatly prefer web apps because I and many other people live a multi device life. If I have an Android phone, a Windows work PC, and a personal MacBook, I need to learn 3 different UIs for a single application. I need to configure them 3 times, manage their settings in 3 places. With a web app I learn 1 UI, I configure it once, I can login on my main PC or my father's Linux laptop and get the same app I'm used to in seconds.

No worrying about making backups for it, no worrying about the permissions I'm giving it, no worrying about the updates each machine is on, or how much space it might be taking up, or if it's using HTTP connections for updates, or that support for my older OS might get dropped, or that it won't hit my new distro for 6 months, or that it's not available in my package manager, or that it will autostart at boot and be an annoyance, or that uninstalling it will leave a bunch of shit behind, or any other of the things that native applications do that annoy me.

I go to a URL, and I use an app in less than a second on any device I own. And if I want, I can quickly go into the browser settings and wipe that app and everything it's touched from the PC in seconds.

That might be optimising for my wanted experience as a user, but I can't please everyone and I see a lot more multi-device multi-OS users who don't want to manage all the details of a native app than I ever do of users that want the opposite.

Re: Offline First – A Better HTML5 User Experience

#145

Post by edem »

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…

Read about high frequency trading. Even a lag spike can cause problems there.

Re: Offline First – A Better HTML5 User Experience

#146

Post by dang »

ebbv wrote: post #96

Dude, I get it. Stop being so condescending. Maybe you're trying to be helpful by including those links but it comes off as incredibly insulting and pedantic. I was talking about a real-time communication application. You can make the argument that the application should try to cope with a sporadic connection, but in the real world this is inefficient for both the user and the staff if the connection is going in and…

Please don't stoop to lashing out personally. Friction is inevitable in an internet forum like HN, so each of us will occasionally be rubbed the wrong way by a comment here. Most of the time this is just a glitch—a crossed signal about intention. But even when the other person really is being condescending and whatnot, it's important for the sake of the community not to make the thread still worse, as you did here.

We detached this subthread from https://news.ycombinator.com/item?id=13247090 and marked it off-topic.

Re: Offline First – A Better HTML5 User Experience

#147

Post by andrewstuart2 »

Chris_Newton wrote: post #136
andrewstuart2 wrote: post #133

Earlier quoted context omitted.

The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated. When assumptions change, you really have a ma…

The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Suppose you change foo from 9 to 10. Was that because you now wanted foo to be 10 specifically, or because you wanted to increment foo and it happened to be 9 before so it becomes 10 now? In isolation, these have the same effect. However, one is absolute and the other is relative, so if…

Right, but the assumption of original state is still invalid. An increment from 9 to 10 might be invalid if, say, the guy has already worked 40 hours and by union contract cannot work any more hours. If it had been corrected to 8 and my intent was either "set to 10" or "increment by one," the values of 9 or 10 are both invalid. So, unless we want to attempt to account for all possible rules (and vastly overspend on the project) the best choice when assumptions are invalidated, regardless of intent, is to surface the conflict.

This is very much just a distributed database where we've chosen availability in the presence of network partitions rather than consistency. The end result is that conflicts will inevitably happen, and aside from a hugely complex set of rules, the cheapest resolution is still human intervention.

Re: Offline First – A Better HTML5 User Experience

#148

Post by stuaxo »

I wish more native apps were offline first.

Take the tripadvisor app; when you go to the website you are nagged to go to the app, if you click you end up in the google play store and it loses where you were.

And of course it only works online; utterly pointless.

Re: Offline First – A Better HTML5 User Experience

#149

Post by tim333 »

c-smile wrote: post #125
krick wrote: post #122

Earlier quoted context omitted.

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.

There are different types of trading. The last few I did involved phoning the bloke at iDealing so he can call the market makers and get back to me a few hours later.

Re: Offline First – A Better HTML5 User Experience

#150

Post by ksk »

0xCMP wrote: post #137
ksk wrote: post #111

Earlier quoted context omitted.

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 Integrit…

Yes and these protections are only used to their full potential on something like iOS. On Windows, macOS, and Linux these are not used to defend your data or system out-of-the-box like they are in a browser. A massive wall with an open gate isn't much of a wall.

Actually, browsers use these very same techniques to make web-apps more secure !!
Post reply on HN