Basically, what’s the difference between the two?
Basically Web Worker was designed to perform high-consumption functions without this interfering in the execution of the main code, that is, does not block the main cycle of the event since it occurs in parallel. Web Worker scripts do not intercept network requests and communicate explicitly through messages.
Already Service Worker was designed to intercept the network requests that normally require as images, scripts and static resources in order to store them in cache and use them later in unstable networks or even in the absence of network (offline) so as not to interrupt the execution of the main code. It is worth only resaltar that Service Worker is the successor standard of the already depreciated Appcache and is one of the fundamental pillars for offline-first as well as being increasingly used to accelerate future accesses to the application.
When to use a Web Worker or a Service Worker?
This point is somewhat subjective but perhaps it is possible to state that more intense operations should be performed in an example Web Worker:
Imagine the case of receiving the format PCM
of a recording of the microphone and encode in the format RAW
using for example some port of LibeLame
(.mp3) in javascript to send to the server, this process becomes costly and running in the main code would block the main event causing interactions and resulting processes to be executed only after the completion of this event. When using this part of the code in a Web Worker the main code would not need to be blocked and would only "listen" to the result of this process through message.
Already Service Worker is more indicated in cases where the application must be available even in the fault (or lack) of the network (offline) or simply to speed up the loading of the page/application example:
If your page/application has many features like fonts, css, javascript or others (json, xml, csv) that do not need to be updated so often bad that has a considerable cost for page loading, consider using Service Worker with the following strategy:
- 1: if not cached... store it
- 2: if already cached... check if there is any later version (and update the cache)
- 3: serve the cached content
Note that the resources coming from the cache do not need to be downloaded from the network and are therefore "accommodated" to the DOM faster and therefore bring an end effect of a much faster rendering.
If the need is exclusively to serve an application "offline" Service Worker can store all kinds of resources obtained through a request GET
including requisitions cross-origem
the only caveat to be put here is to use an appropriate strategy the needs of the application.
Currently we can implement without worries with browser support?
Web Worker is currently supported by major browsers and second whatwg it is available on a cycle "LS" (Living Standard) the table below shows the support of the main browsers (second caniuse with.).
Service Worker in turn is a specification in the definition process currently found in "WD" (draft) second w3c.
Its support and implementation are currently more advanced in Chrome and Firefox in their respective versions "desktop" and "mobile"... other browsers also support it but partially or through the activation of "flags" in the browser’s resource settings. The table below shows the support in the main browsers according to the site caniuse with..
In a simple way it is possible to use Service Worker in the main browsers in a total or partial way that depends on much of the approach in question.
edition (30/11/2017):
For those interested in monitoring the progress of the implementation of Service Worker in major browsers (Chrome, Firefox, Samsung Internet, Safari and Edge) it is worth taking a look at the page maintained by Jake Archibald. It is possible to track in which browsers and their versions the "Features" of Service Worker are available.