How to Improve Frontend Application Performance with Web Workers & TDD

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.

In a recent special edition of our live coding dojo meetups, 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 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 the coding dojo in more detail and at the end of this article we share a few takeaways from this session that you can try on your own.

Part 1: Intro to Web Workers

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.

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 regards to multithreading execution.
• How the render part of the web browser suffers from that, resulting in a poor user experience.

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 trade offs it offers when implementing a more complex solution. Once we finished we were ready to tackle the second part of the dojo.

Part 2: Test-Driven Development

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.

Key Takeaways

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 code. 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 they thought web workers 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, attendees wanted to see more of those kinds of interactions with new APIs that are available in the browser to be used in our day-to-day work. Given such enthusiasm, we are evaluating new web features that we can fit in future editions of our coding dojos.

Who doesn’t want to learn a new api that can provide a better experience for our users when they interact with our applications? If you want to know more and see what is next, Codurance regularly hosts coding dojos - Take a look at our events page so you don't miss the next one.