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

101–110 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#101

Post by RantyDave »

kaoD wrote: post #39
GrinningFool wrote: post #21

Earlier quoted context omitted.

Gtk Qt The list is actually quite extensive: https://en.wikipedia.org/wiki/List_of_platform-independent_G... -- For mobile, clean separations also helps. It is definitely possible - and less complex than you'd expect - to have core functionality in a shared library, wired up to platform-specific native GUI toolkits. But your question illustrates the problem. The pervasive presence of toolkits that add layer upon laye…

I'm mainly an app developer that transitioned (a long time ago) from native to web apps, tired of code duplication. I'm well aware of other options. The web comes with its warts, but I've yet to see an app platform as ergonomic and comfortable for the developer as the web. For 99% of my use cases, anything else is overkill and too much of a hassle. It's not the web's fault that it's a better app platform than actual…

Apple's stuff is actually really nice. Sadly Apple specific, obviously :(

Re: Offline First – A Better HTML5 User Experience

#102

Post by Klathmon »

Nadya wrote: post #99
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?

Can it interop with other applications? eg. can output be piped from another program? Will it still be around to use if the company goes bankrupt? Can settings be backed up at all? Can I even restore settings from a backup? Can I easily share these settings? Is there a way to carry it on a thumb drive so that in the event I find myself without internet for a first install/use - I can still use it? How much control do…

Well to the settings stuff yes, see something like "cookie clicker" for a (IMO bad UX) example. And you can more easily control how much data it stores over a certain point, as all major browsers make you confirm via a dialog that you are giving permission to use the requested amount.

But to keep this from turning ugly, my point was more that you need to take into consideration what you'll need for your app.

If it's an application that basically only exists as an interface for data stored in a backend server, then giving them the ability to exist after bankruptcy is pointless. However if it's something that needs root access and will frequently be used and installed on a system without internet access, native is better.

And saying things like a native app is "less bloated" when it takes literally multiple magnitudes more time to install and run with significantly more permissions to your whole system is silly.

Re: Offline First – A Better HTML5 User Experience

#103

Post by Klathmon »

izacus wrote: post #92
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?

Same way as that worked since 1980ties for all millions of home PC users.

But compared to the web, native applications are significantly worse in these areas.

Especially on that first point. I can go to the vast majority of web apps on just about anything with a browser and get it up and running in less than a second knowing nothing more than a domain name.

And there's "cross platform" then there's "cross platform". Something like QT is amazing, but you are still looking at the big-3 desktop OS's, and maybe the big mobile guys if you work for it. A web app includes all of that, plus my TV, my car headunit, and even my damn watch! (I often use a web home-automation app from a browser on my watch, the UI adapts pretty damn well for quick light-flips)

Nothing is perfect for everyone, but just because it's been done since the 80's doesn't mean it can't be improved on. And as always it depends on your actual needs. There aren't any "better" and "worse" architectures.

Re: Offline First – A Better HTML5 User Experience

#104

Post by substack »

Offline is not a mere feature you can bolt on to existing architectures because you are really building a distributed system. Architectures that work well for distributed systems and especially p2p architectures thrive in this environment. Elsewhere in these comments people are discussing command queues, but this idea presumes that servers are somewhat reliable and that all operations need to go through a centralized point of control and failure. Instead, you can take this idea further and implement a kappa architecture (sometimes also called "event sourcing") where you maintain a log locally on every client which is the source of truth, not a server. When a network connection is available, you can replicate the log to a server or directly to other clients. You can build indexes (materialized views) that sit on top of this log to answer queries more quickly than reading the entire log out every time. You can also blow away these indexes and rebuild them from the log whenever your requirements change (migrations).

Unfortunately the web is missing a few pieces that would make it a very good platform for fully p2p, distributed apps. Service workers are a good start, but they have a 24-hour upper cap on max-age of the service worker itself, so users can't trust on first use (TOFU) and then be more secure against kinds of active targeting. The suborigin specification and iframe sandboxes for distributing apps offline and p2p would be much more useful for offline sandboxes if they didn't require that a server send an http header. These will become much more important as the web bluetooth API matures, which can allow distributing user data and application updates in a totally offline environment.

Even without being fully offline, it's very odd that when an automatic update to android or windows comes down the pipe, people in remote areas download the exact same bytes from servers in America over and over again, all over a thin pipe. They could fetch that data from each other and save a lot of money on bandwidth and data caps.

Re: Offline First – A Better HTML5 User Experience

#105

Post by ibash »

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?

This is similar to what I wrote about here: https://blog.superhuman.com/architecting-a-web-app-to-just-w...

Re: Offline First – A Better HTML5 User Experience

#106

Post by a-guest »

ebbv wrote: post #46

I get where this movement is coming from but I just fundamentally disagree with it. Making offline first web apps may make sense for certain applications where you expect you users may need to use it offline, but it doesn't make sense for all apps and it can require a fundamentally different way of writing your application which is a waste of time and effort if it's not a likely use case for your users.

It does seem the business requirement for real-time is often ignored in "offline first" write-ups. If the current, up-to-the-second status of a server is being monitored, if vital signs for a patient are being monitored, etc., an app only delivers value if it provides the "now"/real-time data. Some form of websocket calls will be used, not Ajax. Showing something from the past because the data was stored locally is not helpful in assessing the current, real-time condition. There may be some things you can do to cater to the condition of being offline, but the point remains this app delivers almost zero business value while offline.

Re: Offline First – A Better HTML5 User Experience

#107

Post by andrewstuart2 »

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…

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 easy to merge without interaction, once we had defined "conflict." And the remaining 5% just required a little extra user experience design to help surface the appropriate resolution.

Re: Offline First – A Better HTML5 User Experience

#108

Post by nooyurrsdey »

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…

wholly agreed. If going offline first fits the use case of your app, then go for it. But there are so many "X-first" approaches (e.g. mobile first) that you can't (and shouldn't) over engineer for them from the start.

Re: Offline First – A Better HTML5 User Experience

#110

Post by DougBTX »

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.
Post reply on HN