This book is dedicated to Katelyn and Rene.
Foreword
The book youre holding now is a fun one. Its a JavaScript book that opens with examples written in C, talks about multithreading with an explicitly single-threaded programming language, provides great examples of how and when to intentionally block the event loop after experts have been telling you for years to never do so, and closes with an excellent list of reasons and caveats about why you might not actually want to use the mechanisms the book describes. More importantly, its a book that I would consider essential reading for any JavaScript developer no matter where your code is expected to be deployed and run.
When Ive worked with companies to help them build more efficient and more performant Node.js and JavaScript applications, Ive often had to step back and take the time first to discuss many of the common misconceptions developers have about the programming language. For instance, I once had an engineer with a long history in Java and .NET development argue that creating a new promise in JavaScript was a lot like creating a new thread in Java (its not), and that promises allow JavaScript to run in parallel (they dont). In a separate conversation someone had created a Node.js application that was spawning over a thousand simultaneous worker threads and wasnt sure why they werent seeing an expected improvement in performance while testing on a machine that had only eight logical CPU cores. The lesson from these conversations is clear: multithreading, concurrency, and parallelism are still very unfamiliar and difficult topics for a very large percentage of JavaScript developers.
Dealing with these misconceptions is what led directly to me (working with my colleague and fellow Node.js Technical Steering Committee member, Matteo Collina) developing the Broken Promises workshop in which we would lay out the foundations of asynchronous programming in JavaScriptteaching engineering teams how to reason more effectively about the order in which their code would execute and the timing of various events. It also led directly to the development of the Piscina open source project (with fellow Node.js core contributor Anna Henningsen), which provides a best-practice implementation of a worker pool model on top of Node.js worker threads. But those only help with part of the challenge.
In this book, Bryan and Thomas expertly lay out the foundations of multithreaded development in general, and deftly illustrate how the various JavaScript runtimes like web browsers and Node.js enable parallel computing with a programming language that includes no built-in mechanisms to enable it. Because the responsibility for providing multithreading support has fallen on the runtimes, and because there are so many differences between those runtimes, browsers and platforms like Node.js implement multithreading in different ways. Although they share similar APIs, a worker thread in Node.js is really not the same thing as a web worker in a web browser. Support for shared workers, web workers, and service workers is nearly universal across browsers, and worker threads have been in Node.js for several years now, but they are all still a relatively new concept for JavaScript developers. No matter where your JavaScript runs, this book will provide important insight and information. Most importantly, however, the authors take the time to explain exactly why you should care at all about multithreading in your JavaScript applications.
James Snell,
Node.js Technical Steering Committee Member
Preface
Bryan and I (Thomas) first met during my interview at the San Francisco branch for DeNA, a Japanese mobile game development company. Apparently most of the upper management was going to say no, but after the two of us hung out at a Node.js meetup later that night, Bryan went and convinced them to give me an offer.
While at DeNA, Bryan and I worked on writing reusable Node.js modules so that game teams could build out their game servers, combining components as appropriate to suit the needs of their game. Performance was something we were always measuring, and mentoring game teams on performance was a part of the job; our servers were continuously scrutinized by developers in an industry that traditionally relied upon C++.
The two of us would work together in other capacities as well. Another such role was at a small security startup named Intrinsic where we focused on hardening Node.js apps at such a complete and granular level that I doubt the world will ever see another product like it. Performance tuning was a huge concern for that product as well since customers didnt want to take a hit to their throughput. We spent many hours running benchmarks, poring over flamegraphs, and digging through internal Node.js code. Had the worker threads module been available in all the versions of Node.js that our customers demanded, I have no doubt we would have incorporated it into the product.
Weve also worked together in nonemployment capacities as well. NodeSchool SF is one such example wherein we both volunteered to teach others how to use JavaScript and create Node.js programs. We have also spoken at many of the same conferences and meetups.
Both of your authors have a passion for JavaScript and Node.js, and for teaching them to others and eliminating misconceptions. When we realized there was such an extreme lack of documentation about building multithreaded JavaScript applications, we knew what we had to do. This book was born from our desire to not only educate others about the capabilities of JavaScript, but also to help prove that platforms like Node.js are just as capable as any other when it comes to building performant services that utilize the available hardware.