How to Use Service Workers to Communicate Across Browser Tabs
This interview has been republished from Versioning, SitePoint’s daily subscription newsletter helping developers stay up-to-date and knowledgeable by offering curated links to the essentials in front-end, back-end, design and UX, news, business and more. Learn more and sign up here.
Tim Evko is a front-end developer, managing a primarily React codebase, and team lead at ExecThread, a company focused on surfacing job openings to professionals. When not at ExecThread, he spends the rest of his time at a local gym, working on being a better competitive Crossfit Athlete.
Which tech idea or trend excites you the most at the moment?
Lately I’ve been fascinated with Service Worker technology, especially when used to help make sites load fast and become interactive quickly. I love performance and web-app-offline capability, and I think the community can benefit from the increased focus on building resilient, versatile, and fast applications.
Service Workers are especially fun to work with because of how much you can do with them. I recently learned that you can use a Service Worker to communicate across tabs in a browser, allowing each individual tab to reload itself if the cache is stale. It’s not an easy technology to work with but I’m very glad that it’s around!
I don’t think I’ve heard of this before – could you go into more detail?
In a browser, Service Workers have control over all clients that are in the available scope, not just the current active tab. This means that when a Service Worker is communicating with a site in your browser, it’ll still be communicating with all tabs that are currently displaying that site. You can take advantage of this feature when using the postMessage API that comes with Service Worker. A detailed example of that can be found here. At ExecThread, we use this functionality to reload all tabs in case a Service Worker serves an old CSS file to a page with new markup on it.
Describe (or link to!) something cool you built, designed or produced recently. Why are you proud of it?
I recently set out to understand how virtual DOM algorithms worked, and in doing so built my very own component render-er: BadDom [github]. It’s 600 bytes and you can build your entire web app with it. I’m proud of it because It’s 600 bytes and you can build your entire web app with it.
BadDOM is actually really simple, and that’s what I love about it. If you give it a node (a div on a page for example) and an ES6 template string, it will update the first div so that it matches the template string. Essentially it’s a DOM-diffing function that makes sure its target will look like the template string.
Since it’s an ES6 template string however, you can add logic to your diffing. This means that you can call the diffing function whenever you update whatever state your logic is based off of, and your original DOM target will match the new state. The whole thing works by creating an invisible element with your template string, and comparing the target element (and it’s children) to find, remove, or modify all DOM nodes until the template string based element and the target element look the same.
It’s efficient because it never updates an element that doesn’t need to be updated, thereby preventing the browser from ever having to do unnecessary work. If you have 100 nested elements and only one class name changes on one of them, BadDom will find the one and only change the class.
How did you build it?
Like most of my projects, I built this on CodePen. I like to focus on keeping things as simple as possible with as little build tools / setup as possible. That way it’s easiest for anyone to understand and contribute to regardless of the platforms or devices they’re using. CodePen is great because I don’t need to set up an IDE to work on Front End libraries. I could talk all day about CodePen, it’s community, and how much I’ve learned from others work on it, but instead I’ll just say that everyone should have a look for themselves.
I like to write all of my JavaScript using the Module pattern, which I did here. The module pattern is a way to write JavaScript so that all code is inside of a self contained object. Methods inside of the object are stored as functions-as-properties, and configuration values can be stored as objects-as-properties. I like to use this pattern because of how easy it is to organize code (especially libraries). You can find more about the pattern here.
What’s the best tech thing you read recently, and why?
Resilient Web Design by Jeremy Keith – Jeremy is an excellent author, and this book is code written exactly as the book states code should be written.
What was the most funny or interesting off-topic link you’ve sent to a friend recently?
On the East Coast, US, it is somehow STILL winter. I sent this to my wife the other day:
This is fine, indeed! There’s this week’s Interviewsioning, thanks to Tim for sharing the tech he’s most passionate about.
