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

41–50 of 150 posts

Re: Offline First – A Better HTML5 User Experience

#41

Post by mbrock »

mark242 wrote: post #38
mbrock wrote: post #26

Earlier quoted context omitted.

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

Yeah, look into using Promise.all. You're probably looking at a good few hundred lines of code reduction. What you're describing as a "command" (request / state update) is just a promise with a map function applied. Your "simple queue thing" can just be an array that you fire Promise.all at.

Can you serialize a promise to localStorage?

How do you deal with network failure in the middle of the promise array?

Re: Offline First – A Better HTML5 User Experience

#42

Post by Nadya »

qudat wrote: post #33
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…

> Disable your web cache and try to use a web application daily. That's like saying "disable a native applications persistent storage and use it daily." It is a meaningless comment.

I can think of valid reasons to disable browser cache/cookies/localStorage that are completely unrelated to the storage of web app data. It is a side effect of web apps primarily using those methods to store user data when they don't want to store anything server side. They are designed to use local storage! That's one of their "perks".

Cookies/cache/localStorage works for most users. I am not most users and I recognize that. My criticism is that the primary method of persistent storage is fundamentally flawed and makes most web apps completely unusable for me.

E:

I'm that person who carries a USB drive of portable software customized to my preferences primarily to be used on friends' machines or for setting up new machines. Setup once and use everywhere. Browser-based storage needs to be setup everywhere by design. I need to setup at Work and at Home because I refuse to tie my personal Home profile with my Work profile, so there is no "syncing" my profile across devices.

If you primarily use one device or can sync between devices and allow cookies/cache/localStorage to persist, then web apps won't be a problem for you at all. If any of the above doesn't apply - then web apps are a thorn in the side.

Re: Offline First – A Better HTML5 User Experience

#43

Post by CorvusCrypto »

Nadya wrote: post #13
ciconia wrote: post #6

Earlier quoted context omitted.

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?

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…

Cannot agree more! However, I can see the appeal of webapps. Getting started in app development using GUI APIs (cross-platform or target-native) can be a bit intimidating, too. And now we have things like electron which... well to me it's slow, but being able to develop a desktop GUI using html5 and css and JS is appealing.

And to be fair, a web app does get the job done, though I have to admit the number of companies that opt for an internal webapp instead of a desktop application is interesting.

Re: Offline First – A Better HTML5 User Experience

#44

Post by wnevets »

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?

Re: Offline First – A Better HTML5 User Experience

#45

Post by brilliantcode »

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…

Do you mean like CQRS/ES?

Re: Offline First – A Better HTML5 User Experience

#46

Post by ebbv »

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.

Re: Offline First – A Better HTML5 User Experience

#47

Post by mark242 »

mbrock wrote: post #41
mark242 wrote: post #38

Earlier quoted context omitted.

Yeah, look into using Promise.all. You're probably looking at a good few hundred lines of code reduction. What you're describing as a "command" (request / state update) is just a promise with a map function applied. Your "simple queue thing" can just be an array that you fire Promise.all at.

Can you serialize a promise to localStorage? How do you deal with network failure in the middle of the promise array?

If a promise in the array is rejected, Promise.all (which returns a promise) rejects with (supposedly) the first rejected promise, but that's extremely hard to predict if you have two promises which could reject.

Serializing a promise to localStorage; I get what you're trying to do, you want to have a worker pick up exactly where it left off when you left the app. This is where a service worker would help you. I suppose you could write some kind of durable mailbox a la Akka, only running in the browser.

Re: Offline First – A Better HTML5 User Experience

#48

Post by kaoD »

CorvusCrypto wrote: post #35
CardenB wrote: post #14

Earlier quoted context omitted.

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

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.

Re: Offline First – A Better HTML5 User Experience

#49

Post by kuschku »

cmdrfred wrote: post #5
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?

My feeling is more people need to stop and think "Why isn't this just a website".

Well, both, in a way.

Many things on the web should be standalone applications, others should be plain documents.

The web should be split into sandboxed programs and epub texts, and we’d be all better off.

Post reply on HN