Live coding with web workers an experimental code kata

Last updated Nov 24, 2024 Published Oct 20, 2023

The content here is under the Attribution 4.0 International (CC BY 4.0) license

In this blog post, we will go over the experience that was to live coding a web worker, if you are not familiar with the features of the browser that are related to PWA, you might want to see the following first:

Introduction to Service Worker - Li-fi, offline first, letting the user take control
Web Workers to the Rescue – How to Work with JSON Strings without Blocking User Interactions

Introduction

Testing web apps is hard work. You’ve probably found that even the code environment can be hostile to testing, with window, documents, event listeners, callbacks, and, to make things even harder, each browser vendor implementing the specs their way. Fortunately, the frontend ecosystem has evolved to a better state, allowing us to even test-drive code that relies heavily on the platform to work.

In this special edition of our coding dojos, we delved into the frontend ecosystem focusing on application performance. The dojo was designed for developers who are familiar with JavaScript and test-driven development (TDD). For this session, we decided to take a randori approach, which is our usual way of coding dojos after experimenting with splitting people up into pairs.

The session began with a brief introduction to our plan. The idea was to divide the coding dojo into two parts: in the first part, we would explore the problem we wanted to solve/code and an introduction to web workers; in the second part, we would apply test-driven development (TDD). The following two sections describe how the coding dojo went in more detail and at the end, we share a few takeaways from this session.

Part 1

The first part of the session was dedicated to introducing web workers. This is a well-supported API for the browser, but it is not as popular among developers as it could be. Web workers offer several advantages, including improved performance for front-end applications. However, they can also add complexity to code maintenance and implementation.

To explore the limitations of JavaScript in the browser, we started with a simple problem: showing and hiding a loading indicator to simulate that computation is happening. With that example, we saw:

the limitation that the javascript has regard to multi-threading execution
how the render part of the web browser suffers from that and user experience is poor

Once we had this done, we started to implement web workers to improve the user experience. In this part, we learned about web workers and the tread-offs they offer when implementing a more complex solution. Once we finished we were done to tackle the second part of the dojo.

Part 2

The second part of the session was all about applying what we learned about web workers in the first part, using test-driven development (TDD). We started by focusing on the business rule we wanted to implement with web workers. We decided to first implement it without workers, and then refactor it to use workers. In the process, we encountered one of the difficulties of test-driving code with web workers:

The Jest library for testing web workers requires you to implement the worker on the fly, instead of using a JavaScript file.
Since you now have a worker, you need to be extra careful when dealing with resources.

We were able to follow the TDD flow without any major restrictions. In the end, we discussed how web workers are ultimately an implementation detail, and that we could keep the same business logic with or without them.

Takeaways

In the end, we were able to learn as a group and better understand web workers. We started with an introduction to the technology and picked a simple problem to start with. Then, we moved to a more complex approach and applied test-driven development (TDD) to our workflow. The main takeaways from the session are:

We gained a better understanding of web workers. One of the attendees even shared that he thought they were more difficult than they turned out to be.
Web workers can add complexity to web applications.
It is possible to test-drive code with web workers and refactor to use web workers in code that is not already using them.

The feedback at the end of the session was positive, and we hope to bring more web APIs that can provide a better experience for our users when they interact with our applications.