Multithreaded Javascript

Chapter 8. Analysis

By now you should be pretty familiar with building multithreaded applications using JavaScript, whether it be code that runs in a user’s browser or your server, or even applications that employ both. And, while this book provides a lot of use cases and reference material, at no point did it say “you should add multithreading to your application,” and there’s an important reason for this.

By and large the main reason to add workers to an application is to increase performance. But this trade-off comes with a cost of added complexity. The KISS principle, meaning “Keep It Simple, Stupid,” suggests that your applications should be so stupidly simple that anyone can quickly look at the code and get an understanding of it. Being able to read code after it has been written is of paramount importance and simply adding threads to a program without purpose is an absolute violation of KISS.

There are absolutely good reasons to add threads to an application, and as long as you’re measuring performance and confirming that speed gains outweigh added maintenance costs, then you’ve found yourself a situation deserving of threads. But how do you identify situations where threads will or will not help without going through all the work of implementing them? And how do you go about measuring performance impact?

When Not to Use

Threading is not a magic bullet capable of solving an application’s performance problems. It is usually not the lowest-hanging fruit when it comes to ...