The Difference Between Web Sockets, Web Workers, and Service Workers

WebSockets, Web Workers, Service Workers... These terms you may have encountered in reading or listening to. Maybe not all, but at least one of them. Even if you are familiar with front-end development, there is a high chance that you will need to find out what they mean. Or you might be like me, sometimes confusing them. These terms look very similar and sound and are easily confused.

Let's break them down together to distinguish between WebSockets, Web Workers and Service Workers. Instead of going deep into the details, doing in-depth research and experiencing each one for yourself—more like a little assistant so you can collect it next time you need to review.

Quick Reference

We will start with an advanced overview for quick comparisons and comparisons.

WebSockets

WebSocket is a two-way communication protocol. Think of it as a constant call between you and a friend that won't end unless one of the parties decides to hang up. The only difference is that you are the browser and your friends are the server. The client sends a request to the server, and the server responds by processing the client's request, and vice versa.

Communication is based on events. Create a WebSocket object and connect to the server, and messages between servers trigger events to send and receive them.

This means that when an initial connection is established, we have a client-server communication where the connection is started and remains active until the client or server chooses to terminate it by sending a CloseEvent . This makes WebSockets ideal for applications that require continuous and direct communication between clients and servers. Many of the definitions I've seen list chat applications as common use cases - you type a message, send it to the server, trigger an event, the server responds with data without repeatedly pinging the server.

Consider the following scenario: You are on your way out and decide to open Google Maps. You may already know how Google Maps works, but if you don't, it will automatically find your location once you connect to the app and track it wherever you go. It uses real-time data transfer to track your location as long as this connection is active. This is a WebSocket that establishes a persistent two-way conversation between the browser and the server to keep the data up to date. Sports applications with real-time scores may also use WebSockets in this way.

The biggest difference between WebSockets and Web Workers (and Service Workers we'll see later) is that they have direct access to the DOM. While Web Workers (and Service Workers) run on separate threads, WebSockets are part of the main thread, which enables them to operate the DOM.

There are tools and services that can help establish and maintain WebSocket connections, including: SocketCluster, AsyncAPI, cowboy, WebSocket King, Channels, and Gorilla WebSocket. MDN has a run list containing other services.

More WebSockets information

• Introducing WebSockets – Bringing Sockets to the Web (web.dev)
• Thinking About Power Usage and Websites (Chris Coyier)
• The WebSocket API (MDN Docs)
• Latest browser support (Caniuse)

Web Workers

Consider a situation where you need to perform a lot of complex calculations while also changing the DOM. JavaScript is a single-threaded application that runs multiple scripts and can destroy the user interface you are trying to change and the complex calculations you are performing.

This is where Web Workers come into play.

Web Workers allows scripts to run in separate threads in the background to prevent scripts from blocking each other on the main thread. This makes them ideal for enhancing the performance of applications that require a lot of operations, as these operations can be performed on separate threads in the background without affecting the rendering of the user interface. But they are not very good at accessing DOMs, because unlike WebSockets, Web Workers run outside the main thread in its own thread.

Web Worker is an object that executes script files to perform tasks by using Worker objects. When we talk about workers, they tend to fall into one of three types:

• Special Worker: Special worker can only be accessed by the script that calls it. It still performs tasks of typical Web worker, such as its multithreaded scripts.
• Share Worker: Share worker is the opposite of dedicated worker. It can be accessed by multiple scripts and can actually perform any tasks performed by the Web worker as long as they exist in the same domain as the worker.
• Service Workers: Service worker acts as a network proxy between applications, browsers, and servers, allowing scripts to run even when the network is offline. We will cover this in the next section.

More Web Workers Information

• "Off the Main Thread" (Chris Coyier)
• The State Of Web Workers In 2021 (Chris Coyier)
• Intro to Web Workers (Zapier)
• Web Workers API (MDN Docs)
• Latest browser support (Caniuse)

Service Workers

There are some things that we as developers cannot control, and one of them is the network connection of the user. Any network that the user connects to is itself. We can only do our best to optimize our applications so that they get the best performance on any connection that happens to be used.

Service Workers is one of some things we can do to gradually enhance the performance of our application. Service workers are located between the application, the browser, and the server, providing secure, separate threaded connections to run in the background, thanks to - you guessed it - Web Workers. As we learned in the previous section, Service Workers is one of three types of Web Workers.

So why do you need a service worker located between your application and the user's browser? Similarly, we cannot control the user's network connection. Suppose the connection is interrupted for some unknown reason. This will interrupt communication between the browser and the server, preventing data from being passed back and forth. The Service worker remains connected and acts as an asynchronous proxy that intercepts requests and performs tasks—even after a network connection is lost.

This is the main driving force for what is commonly called "offline first" development. We can store assets in a local cache instead of the network, provide critical information if the user is offline, prefetch content so that the user can use when needed, and provide a fallback to network errors. They are completely asynchronous, but unlike WebSockets, they cannot access the DOM because they run on their own threads.

Another important thing about Service Workers is that they intercept every request and response from your application. Therefore, they have some safety risks, and most notably they follow a homologous strategy. Therefore, this means that service worker cannot be run from a CDN or a third-party service. They also require a secure HTTPS connection, which means you need an SSL certificate to run them.

More Service Workers Information

• Add a Service Worker to Your Site (Chris Ferdinadi)
• Service worker overview (Chrome Developers)
• Smaller HTML Payloads with Service Workers (Philip Walton)
• Service Worker Cookbook (Mozilla)
• Service Worker API (MDN Docs)
• Latest browser support (Caniuse)

Summary

This is a super-advanced explanation of the differences (and similarities) between WebSockets, Web Workers, and Service Workers. Again, terms and concepts are similar enough that one can be confused with the other, but hopefully this will give you a better understanding of how to differentiate them.

We start with a quick reference table. This is the same, but slightly expanded for a more detailed comparison. (The form should be inserted here, and the content of the form should be rewritten according to the original form content to maintain the original intention)

The above is the detailed content of The Difference Between Web Sockets, Web Workers, and Service Workers. For more information, please follow other related articles on the PHP Chinese website!