How Do We Get It Done, Now?

For web platform enthusiasts, the developing ServiceWorker is a wunderkind among APIs. It’s taking a lot on: offline-first control over assets, performance improvements via network interception and cache management, background process enhancements.

Article Continues Below

It’s cool and I want to use it right away. I want to ride the offline-first wave. But ServiceWorker is in that awkward phase of partial adoption and implementation that raises the question I’ve asked myself before: how do I use this beautiful future thing, now?

ServiceWorker, valiant in shining armor#section2

Briefly, ServiceWorker provides a proxy, letting you make decisions about how to handle and respond to network requests coming from your (client-side) app.

Want to respond to requests for gif files differently if the browser is offline? ServiceWorker can do that. Want to explicitly retrieve assets from the browser cache for certain requests? ServiceWorker in conjunction with its pal the cache API can do that, too. Neat-o.

ServiceWorker is, in part, a do-over for the API devs love to hate: Application Cache, a.k.a AppCache (though, I should point out, ServiceWorker is considerably more functional than AppCache).

The waning antagonist: AppCache#section3

It’s rare that I say “this is really just how it is” about anything to do with web technology but, okay, I’m going to be straight with you: AppCache is awful to work with.

With AppCache, you (ostensibly) create a manifest file of the stuff you want the browser to cache locally. In practice, there are so many ways to get this wrong.

It’s confusing to debug and difficult (sometimes nearly impossible) to rectify if you make a boo-boo—which you will, because it is a cruel master. And it just doesn’t give you fine-tuned control.

Ideals vs. present reality#section4

AppCache is a beast, but it’s been around for several years and is supported by the majority of modern browsers.

ServiceWorker is partially implemented in about 45 percent of the world’s browsers—newer Chrome, Android, Opera browsers. That seems substantial; however, there is no official word that Safari will ever implement it.

Another wrinkle is that ServiceWorker is partially re-implementing something that already exists. There is no straightforward progressive enhancement from AppCache to ServiceWorker. Supporting both probably means writing certain functionality twice.

That means for real-world project architecture, I have several options, each unsatisfying on some level:

  1. Treat offline-first as an enhancement that works in under half of the browsers out there
  2. Write an offline approach using AppCache and then also write it in ServiceWorker for browsers that support it
  3. Write an offline approach in AppCache and leave it at that

Option 1 won’t fly right now if you have a need to support a broad set of users. Option 2 is technically possible, but requires logic duplication and budget-straining extra time. Option 3 is functional but unappetizing.

So now what?#section5

We’re caught in the limbo between the web as it is and the web as we hope it will be soon. My heart is in the future; our reality is in the less full-featured now.

There is an ongoing conflict between what we want to believe is immediately doable and what is, in fact, feasible. I don’t want to suggest an academia-industry divide, because we’re all on the same side here. But we sometimes get wrapped up in the promise and energy of new standards and are blind to their growing pains.

Every new standard has to pass through the shadows of doubt as it makes its way to the light of day. We’ll always need to choose which questing API heroes to throw in with, knowing not every contender can be victorious.

The web demands risks and, dare I say it, courage. Its democracy leads to uncertainty—no one’s entirely in control of this crazy thing. Which is why forward-looking web thinking is considered future-friendly, not future-proof.

I’m not clamoring to put the brakes on the pace of change. We are getting what we asked for, for the most part: accelerating invention and improvement of the web.

But I’d like us to recognize that making decisions about fledgling platform APIs and the changing web is another expertise we have, though we may take it for granted.

And that building the web every day is a leap of faith.

5 Reader Comments

  1. @ScottJensøn, AppCache and ServiceWorkers are such radically different angles to solving the problem that you’d have to explain what you mean for it to make any sense. The point of using ServiceWorkers would be to *avoid* using AppCache in the first place. If you’re going to support AppCache (and therefore iOS users) at all, you’re already going to do a lot of work to separate out static resources and dynamic content. You’ll end up with a website that works everywhere. There won’t be any point to using the ServiceWorkers API because it doesn’t gain you anything if you *have* to also support AppCache to get ~100% browser coverage. Maybe if ServiceWorkers allows you to exploit more data persistence storage you could use WebSQL on iOS and ServiceWorkers on other platforms to store your cached dynamic resources? But, as I said, for for a simple small webapp with reasonably little need for client-side dynamic data storage, it’s hard to justify touching ServiceWorkers if you have to support AppCache anyway.

  2. ServiceWorks is a proxy server that sit between web applications, and the browser and network which are designed to improve offline experiences. IT works very similar to cache memory. It intercepts the network requests and take appropriate action based on whether the network is available and update assets that reside on server. They will also allow access to push notifications and background sync APIs.
    This Service is well suited for web-based applications or mobile applications where server interaction is too often.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA