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

21–30 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#21

Post by GrinningFool »

ciconia wrote: post #6
kqr wrote: post #3

I sense a trend of trying to cram everything good about native apps onto the web. Do people who do this stop to think whether the web is actually the correct platform for their app?

If you need to build cross-platform apps - and that is mostly the case nowadays - the web is actually not such a bad solution. I mean, what is the alternative?

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 layer to create "cross platform" are the new norm. People are literally losing awareness that other options exist - much to the detriment of end users.

We have built an entire industry around such tooling - and long ago stopped questioning what value it brings.

Re: Offline First – A Better HTML5 User Experience

#22

Post by yonkshi »

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 up building a very special purpose buffer on both client and server side.

Re: Offline First – A Better HTML5 User Experience

#24

Post by ksk »

kqr wrote: post #3

I sense a trend of trying to cram everything good about native apps onto the web. Do people who do this stop to think whether the web is actually the correct platform for their app?

They do, but they're convinced that asking people to install software is verboten.

Re: Offline First – A Better HTML5 User Experience

#25

Post by augbot »

afarrell wrote: post #4

Doesn't Chome on iOS prevent this because it reloads whenever you re-open a page, even if you don't have an internet connection?

Totally good point; a quick test of the latest beta iOS, Safari seems to reload some pages and not others (window.focus?) So, it seems to be whatever JS magic the sites are using are handling a reload (latest ads! weeeeeeeee!!!)

Re: Offline First – A Better HTML5 User Experience

#26

Post by mbrock »

mark242 wrote: post #19
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 suspect that using Promise.all() helps greatly with this.

The way I've done it is to just have an array of commands and a simple queue thing that keeps retrying its head element until success, triggered by connectivity change or manual user retry.

(This was also useful when our backend had random issues causing 500s sometimes.)

A command has both an AJAX request and a state updating function. It's really easy with a React-like framework because you can just apply the command queue's state changes as part of the main view render, without actually modifying the main state.

Re: Offline First – A Better HTML5 User Experience

#27

Post by tannhaeuser »

CaptSpify wrote: post #16
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?

Maybe I'm mis-understanding but it sounds like your talking about something entirely different? Some sites just wouldn't work well with HTML+optional JS. Google maps (IMHO) would not work well that way, so using an offline-oriented model would make better sense. That being said, if your a news site, or a blog, yeah, a simple static page is probably a better solution.

Of course true webapps can benefit from an MV* approach (like enterprise-type LOB apps). But gmaps IMHO isn't a good example, as it isn't MV*; rather, it fetches prerendered bitmap or vector graphics from the server.

Re: Offline First – A Better HTML5 User Experience

#29

Post by Nadya »

CardenB wrote: post #14
Nadya wrote: post #13

Earlier quoted context omitted.

There is plenty of software that works across Windows/Mac/Linux/Unix-like platforms. They run faster, don't always need an internet connection, are easily portable, and are typically better designed and less bloated than any web-limited cross-platform application. They also don't rely on browser cache or localStorage for settings and I don't need to login daily to access my stuff. Disable your web cache and try to us…

Aren't there lots of caveats for each platform when using so called "cross-platform" code?

Yes - totally! You either limit yourself more or double/triple your work making different system API calls depending what platform you're compiling for. Not too different from tripling your workload to support "offline" applications or dealing with IE/Safari/Chrome/Firefox differences.

Most web apps I've come across either don't run in IE or have various bugs/issues in Firefox as most of them are coded on and targeting Chrome due to Chrome's dominance of the web. Which reminds me of people building/testing only on Windows.

I will admit that the comparison I'm drawing are "same but different" problems. Browsers are a lot more standardized than operating systems and fixing a difference between Firefox/Chrome is usually a lot more trivial than fixing a difference between Windows/Mac.

Re: Offline First – A Better HTML5 User Experience

#30

Post by CorvusCrypto »

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…

is there anything more you can say about your buffer solution? Curious if it is something similar to vector clock syncing that you guys came up with.
Post reply on HN