For a while, the differences between native apps and web apps were readily apparent. But recently, the lines have begun to blur. In conjunction with the growing capacities of browsers, service workers are giving developers the ability to build into web apps functionality that was once out of reach.
What are service workers? And what do they help us do? These are the questions we’ll be looking at in this article. Today, we’ll be taking a brief overview of what they are. In the articles to follow, there will be more specifics about implementation.
The Need
When compared to native apps, web apps have faced a number of challenges over the years. How does a web app, for instance, provide a rich offline experience? Or utilize periodic background syncs, or push notifications? These are features that at one time required a native app. But that is beginning to change.
Service workers are not the first attempt at solving these challenges. Other solutions have been developed over recent years, but although they seemed promising, they continued to fall short. In the words of the W3C,
“…the long lineage of declarative-only solutions (Google Gears, Dojo Offline, and HTML5 AppCache) have failed to deliver on their promise. Each successive declarative-only approach failed in many of the same ways, so the service worker effort has taken a different design approach: a largely-imperative system that puts developers firmly in control.”
In contrast to these previous solutions, service workers follows an imperative approach, giving developers much more control over their applications. In so doing, it avoids some of the pitfalls of previous solutions (e.g. the gotchas of AppCache), and helps provide a foundation for building offline-first web applications in a natural way, as well as providing a background execution context that can be effectively used by web applications.
What Is a Service Worker?
Technically, a service worker is a type of web worker — a script your browser runs in the background, separate from a web page. Here are some important aspects of this kind of worker:
It’s event-driven
A service worker is an event-driven worker that takes the form of a JavaScript file. It begins its life when events are sent to it, and can end between events. If there are no events, the browser can shut down service workers at its discretion in order to free up resources.
One of the implications of this is that you cannot rely on global state within a service worker. If there is a need for persistent data across restarts, though, service workers can make use of the IndexedDB API.
It acts as a proxy server
The service worker essentially acts as a proxy server between the web application, the browser, and the network. As a network proxy, service workers give developers the ability to control how the network requests from their pages are handled. This is a very important aspect of service workers, and gives the developer a lot of power.
This ability is also one reason that service workers require HTTPS. Since they can intercept and modify network communication, it is imperative that they not be compromised (by a man-in-the-middle attack, for instance). By requiring HTTPS, the browser can confidently know the service worker it’s working with hasn’t been tampered with.
It has its own global script context
The service worker runs in its own separate global script context, separate from the main JavaScript for the page. Having it separated means it will be non-blocking, which can be useful for having it do background tasks without affecting the performance of the page itself.
One related aspect, though, is that as web worker, it has no direct access to the DOM. It’s totally separate from the page, so in order to affect change to the page’s DOM, it would have to do so indirectly, communicating with the page itself, and then having page manipulate the DOM.
The Possibilities
Because of the ability to intercept network requests, and to run in a separate script context, service workers make several things possible for developers:
- The ability to create a richer offline experiences
- Background sync APIs
- Push notifications
- Performance enhancements, like pre-fetching resources and smart caching
- Responding to resource requests from other origins
- Hooks for background services
- Ability to receive centralized updates of expensive-to-calculate data
- Client-side compiling and dependency management of JS/CSS resources
These are great possibilities, but are there any downsides?
Support
The one major hurdle for service workers is the technology isn’t yet supported in all major browsers. Currently, the support is at 60.7%, with both Chrome and Firefox providing the ServiceWorker API in their browsers. IE/Edge and Safari are the main exceptions. And although IE will never have service workers, at least Edge and Safari have shown signs of progress. Jake Archibald’s Is ServiceWorker Ready? provides a regularly updated status of the situation.
Getting Started
In the coming articles, we’ll look at how to actually implement some of these features using service workers. In the meanwhile, here are a few links to resources that will provide more information about this promising and useful technology.