Live coding with web workers an experimental code kata
The content here is under the Attribution 4.0 International (CC BY 4.0) license
In this blog post we will go over the experice that was to live code a web worker, if you are not familiar with the features of the browser that are related with 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
Testing web apps is hard work. You’ve probably found that even the code environment can be hostile to testing, with windows, documents, event listeners, callbacks, and, to make things even harder, each browser vendor implementing the specs their own 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.
For this session, we decided to take a randori approach, which is our usual way of doing 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 in the end we share a few takeaways from this session.
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 frontend applications. However, they can also add complexity to code maintenance and implementation.
With that example we saw:
- 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 it offers when implementing a more complex solution. Once we finished we were done to tackle the second part of the dojo.
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:
- 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.
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.