Lyza Danger Gardner on Building the Web Everywhere: 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.

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

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

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

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?

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.

via planetweb

Tweet