Offline First – A Better HTML5 User Experience

http://www.joelambert.co.uk/article/offline-first-a-better-html5-user-experience/

by openmaze • 10 years ago

434 144 10 years ago

joelambert.co.uk

tannhaeuser3• 10 years ago

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?

niftich• 10 years ago

(2012)

The article is older but the advice is sound: only reach out to the server when you need to and ensure your client-side state doesn't break when you can't.

It's a little strange that they avoided naming any JS MV* frameworks even though some where out by then -- Backbone, Knockout, Ember, Angular, if I recall. But this article makes the point that all future JS MV* development went on to consider best practice in the years to follow.

JustSomeNobody2• 10 years ago

Why is it strange? If one starts naming frameworks, one's blog post would be outdated by the next week.

- only slightly sarcastic.

CorvusCrypto9• 10 years ago

Depends, if you are content-driven and can generate and cache static HTML and that's all you need I say hell yes, send that only, give it an e-tag, call it a day. ezpz. I gave benefit of the doubt to the author though and imagined an application that utilizes a decent amount of data that changes fairly frequently. In this case I can see the want for reducing the actual data sent over the wire and moving to a microservice infrastructure for the data with minimal logic server-side.

tannhaeuser3• 10 years ago

I didn't mean to refetch HTML partials. You can still re-fetch JSON and render it on the browser eg. what jquery web apps did, and mostly do still (even though less prominently featured on HN).

CaptSpify• 10 years ago

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.

tannhaeuser3• 10 years ago

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.

kqr• 10 years ago

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?

cmdrfred• 10 years ago

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

kuschku• 10 years ago

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.

ciconia• 10 years ago

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?

Nadya4• 10 years ago

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 use a web application daily. I wouldn't use software that constantly resets or removes my config files as a side effect of some other action.

GrinningFool• 10 years ago

Gtk

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.

ksk5• 10 years ago

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

AgentME2• 10 years ago

Smart users don't like installing every little thing they want to try and giving them all full unsandboxed access to their computer.

On the desktop, the easiest way to run an app in a sandbox is if it's a web app that runs in the browser's sandbox to begin with.

qudat2• 10 years ago

There are more developers for the web than for C++ GUI applications. Building a cross-platform application using C++ is not a simple task in the slightest and it's even more difficult finding talented developers to accomplish the goal.

It seems like a no-brainer to me, building a cross-platform application use web technologies makes the most sense from a business pov.

mbrock17• 10 years ago

There is a huge number of applications for which the web is pretty much the only platform that makes any sense at all.

Compared to making a cross platform native application that works on Linux, Mac, Windows, Android, and iOS, making a web app—even with offline support—is delightful and efficient.

afarrell• 10 years ago

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?

augbot• 10 years ago

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!!!)

RandomInteger4• 10 years ago

I think there is a flag under chrome://flags where you can turn off automatic page reloading if the system is disconnected from the internet.

That being said, doesn't appcache provide the offline page if the browser can't connect?

CorvusCrypto9• 10 years ago

I see the author's vision, but I have to say that I still favor progressive enhancement over this. Using javascript only assumes a lot about the user even in this modern age of web development.

Also as a nitpick, I would say don't make your data objects SINGLETONS, make them SINGLE INSTANCE.

EDIT: someone deleted their comment but brought up a good point that you can have progressive enhancement with this. Yes, however the author made it clear he favors the JS or nothing approach. And there's even this snippet:

An offline first approach would be to move the entire MVC stack into client side code (aka our app) and to turn our server side component into a data only JSON API.

mark2425• 10 years ago

Here's your user assumption: 99.8% of browsers have Javascript turned on. Creating a fallback version of your app that works without Javascript is basically like developing for IE 5 -- you are completely wasting your time.

Here's another one: mobile browsers make up a majority of web traffic now, and Chrome and Safari are pretty well split in terms of share. Sending HTML tags over the wire is a waste of your users time. The idea of "progressive enhancement" should be thought of more as, "what can we display quickly on our user's screen while we're downloading and parsing the Javascript to make the application work". Note that this doesn't mean loading screens, just an initial state which shows the user progress in building up the app from that initial http connection. Regardless of the negativity around AMP, Google has made us think about what exactly we need to do in order to provide a good experience quickly and a feature-rich experience within a couple of seconds.

CorvusCrypto9• 10 years ago

Progressive Enhancement was laid out clearly actually so that basic content should be accessible to all web browsers and basic functionality should be accessible to all web browsers.

As for google, they also recommend using progressive enhancement and they even removed their ajax SE scheme posting about this wherein they even give a recommended trick for compatibility testing.

https://webmasters.googleblog.com/2015/10/deprecating-our-aj...

mark2425• 10 years ago

tldr: Someone wrote a bunch of paragraphs and LOC around JSON.parse(window.localStorage.getItem(key)).

If you're really interested in learning about creating a workable offline web app, Google has some great documentation. https://developers.google.com/web/fundamentals/instant-and-o...

Last, the Safari team needs to seriously get to work on Service Workers. We will see web apps grow by leaps and bounds once the service worker spec is opened up to iPhone users.

peller• 10 years ago

We will see web apps grow by leaps and bounds once the service worker spec is opened up to iPhone users.

Sounds exactly like what Apple doesn't want; no 30% revenue cut, no walled garden of control, ...

mbrock17• 10 years ago

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 change real.

While the client's command queue is nonempty, the UI shows a spinner or equivalent. If commands cannot be realized because of network failure, the UI remains functional but with a clear warning that changes are waiting to be synchronized.

(The API for connectivity status are useful for making sure that the command queue resumes syncing when the user's internet comes back.)

mark2425• 10 years ago

I suspect that using Promise.all() helps greatly with this.

mbrock17• 10 years ago

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.

yonkshi• 10 years ago

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.

CorvusCrypto9• 10 years ago

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.

Pxtl• 10 years ago

What was the challenge with circular relationships? I work on an offline-first system and all inter-object relationships are managed by GUIDs, so cyclical references don't present any problems - objects are sent and received as one big list keyed by guids, not as a tree.

jinjin2• 10 years ago

Did you consider using an off-the-shelf solution like Realm?

In my experience it made it trivial to handle the synchronization of arbitrarily complex object graphs (including those with circular dependencies).

blazespin2• 10 years ago

Yes, This. I struggled with understanding how I'd deal with a complex offline multi user collaborative web app until I starting looking at in terms of a Kafka queue. Gives you everything, including undo/history.

Any suggestions on front end frameworks?

mbrock17• 10 years ago

I implemented such a solution in a React app and I really appreciated the ability to apply pending state changes without mutating the state itself.

I don't know of any open source libraries for the command queue itself. If your state changing commands go through some kind of layer that you control then this stuff is easier. When I implemented it, I first refactored all the commands to go through the same code path, which I could then modify to implement the queue.

wnevets• 10 years ago

Know of any good examples/tutorials of this?

mbrock17• 10 years ago

Unfortunately not, but if you think of it as using the command pattern in a queue-ish way to get a similar behavior as the command queue of "The Sims", you have the basic architecture, and from there it's just a matter of coding.

The thing about React-like frameworks that makes it very nice is that you can keep the command queue in a separate place and have a root rendering function like this:

1. Set the view state to a copy of the actual state

2. Update the view state according to each queued command in turn

3. Render the view state including a status bubble showing that some changes are not saved yet

And separately from the rendering, you have a worker that tries (and retries) to perform the queued commands. When a command is successfully performed, it's removed from the queue and its effect on the state is saved in the actual state.

Since I can't find anything on Google when searching for "react command queue" it would be cool to write a blog post with a simple example, but I don't know when I'd have time, so I encourage anyone who's implemented a similar thing to go ahead.

ibash• 10 years ago

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

brilliantcode• 10 years ago

Do you mean like CQRS/ES?

mbrock17• 10 years ago

It makes a lot of sense in an event sourcing context because the code used for applying events can be the same in the optimistic case and in the real updates.

In our case, we weren't using an event sourcing architecture, but this client side pattern can be used anyway.

thenipper• 10 years ago

That feedback that the commands are queued or can't be processed is key. I encountered an issue on an app I manage at work where the UI showed that a certain state changing action had taken place before it was resolved on the sever. Needless to say it caused a variety of issues as users thought the system had processed a significant action(hiring a candidate) when they hadn't.

freditup• 10 years ago

What about in cases where the commands may fail because of the actions of other users? For example, say you had a virtual market in a game and someone did a "buy from John" command while offline. they then proceed to use this purchase to beat future levels. However, once the user reconnects online, it turns out that John already sold to somebody else, and thus their purchase and everything after it is invalidated.

In your command queue pattern, what sort of ways do you handle this? Have certain "chokepoints" where the user must be online to proceed? What if you have an app where that sort of chokepoint seems to occur too frequently to make the queue useful?

Edit: I think this is similar to Fiahil's sibling comment, also relevant points made there. Thanks for the quality thoughts everyone!

JoelMcCracken• 10 years ago

The real thing is, it is important to synchronize with the server at that point, otherwise something could be invalid.

It may not be possible to make every app work while offline. You'll probably want to potentially disable certain features while offline, such as store purchases (or, at least, queue them up, but don't show them as having been successfully purchased)

smackmybishop• 10 years ago

That case would probably need server synchronization to confirm, but other cases can be handled with operational transformations.

https://en.wikipedia.org/wiki/Operational_transformation

mbrock17• 10 years ago

That wasn't a big problem in our particular application, so in case of failure we would just report a potentially unsatisfactory error message along the lines of "Your changes could not be saved. Please try again." (with a list of the discarded commands' descriptions).

In a situation where this kind of thing was more important, I would think about how to let the user decide how to reconciliate their changes. It could be that a choice of discarding or retrying would suffice, or something more complex.

The "chokepoint" notion is also useful, and in fact our app did have a distinction between potentially offline actions and necessarily synchronous actions, but our synchronous actions were mostly queries like searches.

ramzyo• 10 years ago

This makes so much sense. Would have saved me many headaches when developing an offline app a few years ago.

Fiahil• 10 years ago

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 buy it on my mobile. When the net comes back, did I mean to buy this item two times or just one ? In this case, it's easy to find a workable solution (cancel the second order command), but you get the idea: It's not trivial.

CQRS and ES, are wonderful tools in such situations. Past that point, your web app is far away from the little CRUD mashup it was at the beginning.

mbrock17• 10 years ago

Yeah, heavy transactions like purchases need special care, but that's true in general. At least you'd want a confirmation from the user.

In our case, a simple command queue solved the vast majority of use cases, and the corner cases were not disasters but at worst somewhat confusing.

andrewstuart23• 10 years ago

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.

pkaeding2• 10 years ago

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/

rattray• 10 years ago

CQRS = Command Query Responsibility Segmentation – http://martinfowler.com/bliki/CQRS.html

ES seems to be Event Sourcing – http://martinfowler.com/eaaDev/EventSourcing.html

sgk284• 10 years ago

I'm a big fan of command queues, but if there is a chance of a server-side failure that can't be realized immediately on the client (e.g. an edit conflict with a different user editing a same piece of information), then I find that surfacing those errors in a meaningful way can be difficult and frustrating for the user.

By the time the client has synced with the server, the client could be doing something completely unrelated in an entirely different part of the app. Explaining to them that "the thing you were editing two hours ago has an issue, go here to resolve it" can be tricky.

mbrock17• 10 years ago

Yeah, it can get tricky, but it's a tradeoff between working nicely in the majority of cases and being accurate in the corner cases.

If you make sure to show the user a clear warning that they're working offline, then they might be more understanding if their changes are rejected two hours later.

mjevans• 10 years ago

Treating changes more like emails/outgoing order forms might be useful here.

You could popup a /failure/ message and leave a little indicator icon that takes them to the queue and lets them see the items that failed. If retry is an option they can see it, if retry is not an option they can be told why.

amelius3• 10 years ago

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?

mbrock17• 10 years ago

Sorry, I don't understand. Could you give an example?

heisenbit• 10 years ago

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.

mozumder• 10 years ago

That's nice and all, but no one is going to have all the images/videos/audio available offline for their media sharing social network app.

Web servers exist so you don't have to have all that data locally.

blazespin2• 10 years ago

Maybe add 2012 to title on HN. As that's from when this post is.

wslh• 10 years ago

I think this is an exception, until we don't have a good offline experience this article will be current.

AgentME2• 10 years ago

It is missing anything about ServiceWorkers.

BorisMelnik• 10 years ago

very interesting - I'd love to see a feature like "queue / share later" (maybe Buffer etc) to share when you get back online again.

robwormald• 10 years ago

You might find https://developers.google.com/web/updates/2015/12/background... interesting?

ebbv4• 10 years ago

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.

jedberg2• 10 years ago

All mobile apps will be offline at some point. Cell coverage doesn't cover 100% of the planet yet.

The question is, how good of an experience will you be able to deliver when your client is inevitably in one of these places?

ebbv4• 10 years ago

Of course but if you're writing a web app who's only purpose, for example, is to talk to support staff for your company then having an offline mode is not really useful. If you're offline you can't talk to the staff, so all the app needs to do is fail gracefully. Designing it "offline first" would be silly.

I actually believe that >50% of web apps probably fall into this category, where they really cannot function properly offline because the online-ness s core to their functionality. That's why they are web apps in the first place.

Now if you are designing a web app that is a web version of a more traditional native app like Google Docs or something, then sure offline first makes sense. But I don't think that's the majority of web apps.

a-guest• 10 years ago

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.

cryptarch• 10 years ago

How about offering a HTML experience in the first place?

I'm really tired of "HTML" websites that are actually a heap of Javascript writing to a virtual DOM, with only a few references to scripts, most of it being for surveillance (e.g. ad trackers, surveillance for profit with the side effect of it being available to intelligence services via subpoenas, gag orders and secret courts).

c-smile3• 10 years ago

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 storage/caching approach. "Offline first" is too broad.

greenyouse• 10 years ago

There are a few more patterns as well if you use ServiceWorkers. Jake Archibald has a great "offline cookbook" article that lays out other common use cases and strategies.

[0]https://jakearchibald.com/2014/offline-cookbook/

nooyurrsdey• 10 years ago

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.

DougBTX• 10 years ago

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.

c-smile3• 10 years ago

Yes. Yet some applications even have different connectivity models for different modules. Reality is as usual is not that black and white. Truism of course but still.

krick• 10 years ago

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, say, messaging client.

c-smile3• 10 years ago

At the age of electronic trading that 10 seconds off-time of your trading terminal makes it almost useless.

edem2• 10 years ago

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

opvasger• 10 years ago

I feel like commenting on the callbacks and variable-bound-contexts, and saying something about the glorious wonder of modern JavaScripts... better not, tho :)

jedberg2• 10 years ago

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 is bad, which you should always do, whether it's an app or two microservices, then you'll have a more robust system.

intrasight• 10 years ago

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.

fareesh• 10 years ago

Anyone using PouchDB + CouchDB in production to solve this type of problem? It is my go-to solution but I'm unaware of problems at scale.

joelambert• 10 years ago

Wow, cool to see this resurface again! I wrote this ~4 years ago and the web has come on along way in that time. New features such as service workers are definitely making offline a lot easier.

On the subject of progressive enhancement, I'm a huge advocate and believe it is in general the way todo content sites. As has been pointed out above though, some use cases do require a different approach. For context this was post was written after working on a number of HTML5 apps that were wrapped in Cordova/PhoneGap.

tyingq• 10 years ago

I would throw in some guidance that says "don't trust anything the client side sends to you". Developers used to server side MVC could expose themselves to client-side manipulation that open up some security issues.

I remember some early ecom cart implementations where you could "name your own price" as an unintended feature.

foxhop• 10 years ago

Offline First versus Resilient Web

ebbv4• 10 years ago

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 out and they are trying to hold a conversation it might be better to show the user a message that says hey your connection is down try later when you have a better connection or try an asynchronous support method like submitting a ticket.

Regardless that was just an example off the top of my head. My point still stands; web applications are web applications for a reason, and "offline first" doesn't make sense for most of them.

mbrock17• 10 years ago

I disagree and I explained why. Telling me what the "real world" is like is the same condescension you complain about.

If a couple of links to articles is "incredibly insulting" to you then you shouldn't discuss stuff on the internet.

ebbv4• 10 years ago

Your example indicates you don't get it. You mention responses "from yesterday". That's not going to fly in an application that's real time that requires staff to keep the conversation open. You're describing a ticket system, I'm describing a live chat system.

I said "in the real world" as opposed to abstract talking about an application; in the real world a staff member would be stuck waiting for the response from this user where you're trying to keep the conversation going despite their sporadic connection. I guess I could have said "in meatspace" or something.

Links to explanations of the topic being discussed is of course incredibly insulting. Come on.

Anyway, whatever man. You are not pleasant to talk to so I'm done.

dang• 10 years ago

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.

substack• 10 years ago

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.

cmurf• 10 years ago

It continues to baffle me how much on disk cache is used by web browsers, but won't be used to load a page I know is in the cache if I'm offline.

yellowapple• 10 years ago

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.

DecoPerson• 10 years ago

I'm surprised no one has mentioned Meteor[0].

[0] https://www.meteor.com/

flippyhead• 10 years ago

Me too. We picked Meteor specifically because it's approach incorporates ideas that make doing offline a lot easier.

edditoria• 10 years ago

And me too. Meteor becomes my most favourite development framework in 2016. The ability of offline and data sync are some-kind of "by default" once I start a project, or just a simple test on idea.

Plus, packing it into a desktop app is lightening fast. It is a "wow" factor for potential clients.

dimino• 10 years ago

How do you write unit tests for something like this? Are there frameworks that make this kind of model easier to deal with?

edem2• 10 years ago

Funnily this site does not wor k well with my crappy mobile connection. It loads 3 paragraphs and strangely the 4th paragraph is cut in half. I waited a minute for it to load.

stuaxo• 10 years ago

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.

Offline First – A Better HTML5 User Experience

Related Stories