This article is excerpted from SitePoint's Daily Subscription Newsletter Versioning, which provides developers with selected links in front-end, back-end, design and user experience, news, business and other fields to help them maintain the latest knowledge and information. Learn more and sign up to subscribe, visit here. 
Tim Evko is a front-end developer who manages a code base based primarily on React and is also the team leader of ExecThread, a company that focuses on providing job search information to professionals. In his spare time, he will exercise in the local gym and is committed to becoming a better competitive Crossfit athlete.
What are the technical concepts or trends you are most interested in at the moment?
I've been obsessed with Service Worker technology lately, especially for faster website loading and fast interaction. I love the performance and the offline functionality of web applications, and I think the community can benefit from a greater focus on building resilient, universal and fast applications. Service Worker is particularly interesting because it can implement a lot of features. I recently learned that it is possible to use Service Worker to communicate between browser tabs, allowing each individual tab to reload itself when the cache expires. This technique is not easy to master, but I am very glad it exists!
I don’t know much about this technology, can you introduce it in detail?
In the browser, Service Worker can control all clients within the available range, not just the currently active tabs. This means that when Service Worker communicates with a website in the browser, it will still communicate with all the tabs that currently display the website. You can take advantage of this feature when using the postMessage API that comes with Service Worker. Detailed examples can be found here. In ExecThread, we use this feature to reload all tabs in case Service Worker provides the page with old CSS files with new tags.
Please describe (or link to!) interesting works you have recently built, designed or produced. Why are you proud of this?
I recently started to understand how virtual DOM algorithms work, and in the process I built my own component renderer: BadDom [github]. It only has 600 bytes and you can use it to build your entire web application. I'm proud of this because it's only 600 bytes and you can use it to build your entire web application. BadDOM is actually very simple, which is why I like it. If you provide a node (such as a div on the page) and an ES6 template string, it will update the first div so that it matches the template string. Essentially, it is a DOM differentiation function that ensures that its target looks like a template string. However, since it is an ES6 template string, you can add logic to the differentiation. This means that you can call differentiation functions at any time to update any state your logic is based on, and your original DOM target will match the new state. The entire process finds, deletes, or modifies all DOM nodes by creating an invisible element using the template string and comparing the target element (and its children) until the elements based on the template string and the target element look the same. It is efficient because it never updates elements that do not require updates, thus preventing unnecessary processing from the browser. If you have 100 nested elements and only one of them has the class name changed, BadDom will find the element and change only its class name.
How did you build it?
Like most of my projects, I built it on CodePen. I like to focus on keeping it as simple as possible and minimizing build tools/settings as possible. This way, no matter what platform or device they use, it is easier for anyone to understand and participate. CodePen is great because I don't need to set up an IDE to handle the front-end library. I can talk all day about CodePen, its community, and what I learned from other people’s work, but I just say everyone should look at it for themselves. I like to write all JavaScript code using module pattern, and here I do the same. Module pattern is a way to write JavaScript, and all code is located in a self-contained object. Methods within an object are stored as function attributes, and configuration values can be stored as object attributes. I like using this pattern because it is very easy to organize the code (especially the libraries). You can learn more about this mode here.
What is the best technical article you have read recently and why?
Resilient Web Design by Jeremy Keith - Jeremy is an excellent author, and the code in this book is written exactly as the code described in the book.
What is the most interesting or funniest non-themed link you sent to your friends recently?
It's still winter on the east coast of the United States. I sent it to my wife a few days ago: 
It's true! This is the Interviewing this week, thanks to Tim for sharing his most passionate technology. 
FAQs (FAQs) about using Service Worker to communicate between browser tabs
Service Worker is a kind of web worker. It is a JavaScript file that controls the web pages/webses associated with it, intercepts and modify navigation and resource requests, and caches resources in a very meticulous way to complete an offline experience or improve performance.
To use Service Worker to communicate between browser tabs, you need to register Service Worker first. After registering, you can use the postMessage API to send messages between the Service Worker and the page. The Service Worker can then broadcast these messages to all tabs under its control.
To process Service Worker messages for multiple tabs at once, you can use the clients.matchAll() method. This method gets all clients under the control of Service Worker and sends messages to each client. This way, you can ensure that each tab processes messages only once.
No, Service Worker cannot be used for browser-to-browser communication without a server. Service Worker is designed to enable offline experiences and improve performance by caching resources. They can communicate between pages and Service Worker and between tabs under Service Worker control, but they cannot communicate directly between browsers.
The postMessage API plays a crucial role in Service Worker. It allows you to send messages between the page and the Service Worker and broadcast messages to all tabs under the control of the Service Worker. This is how Service Worker communicates between browser tabs.
To register a Service Worker, you need to use the navigator.serviceWorker.register() method. This method takes two parameters: the first is the path to the Service Worker file, and the second is the option object. After registering for Service Worker, it can control the page/site.
Yes, Service Worker can significantly improve the performance of your web pages/websites. By caching resources in a meticulous way, Service Worker can provide an offline experience or improve performance by providing cache resources instead of making network requests.
To use Service Worker to provide an offline experience, you need to cache resources. When a Service Worker intercepts navigation or resource requests, it can respond with cached resources instead of making network requests. This allows the page/site to work properly even when offline.
The clients.matchAll() method in Service Worker is a method to obtain all clients under the control of Service Worker. This method is useful for broadcasting messages to all tabs under Service Worker control.
No, Service Worker cannot be used with WebRTC. Service Worker is designed to enable offline experience and performance enhancements, while WebRTC is designed to enable real-time communication between browsers. These two technologies serve different purposes and cannot be used together.
The above is the detailed content of How to Use Service Workers to Communicate Across Browser Tabs. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
