When I first started working with JavaScript, I had always believed it was strictly single-threaded. That’s what every tutorial, every article, and every senior developer I talked to had told me. JavaScript runs on a single main thread, executing code line by line, and there’s no concept of true multi-threading like in Java or C++.

I accepted this as fact—until I hit a roadblock while building a high-performance service.

My project required processing large datasets while keeping the UI responsive. I noticed that every time a heavy computation ran, the entire application froze, making it frustrating to use. That’s when I realized I needed a solution to handle background processing.

I began my research and came across Web Workers in browsers and worker_threads in Node.js. This was fascinating. These workers allowed me to run tasks in the background without blocking the main thread. It almost felt like multi-threading! Excited, I quickly implemented Web Workers, expecting them to magically fix everything.

And to some extent, they did. The UI became much more responsive, and long-running computations no longer froze the screen. But then, I hit my next big challenge.

I needed my worker threads to access the same objects and data structures as the main thread. But when I tried passing objects, something strange happened—JavaScript refused to send class instances or functions between threads. Instead, everything was copied, not shared.

That’s when I learned about structural cloning—JavaScript’s way of copying objects when sending them between threads. Unlike languages with true multi-threading, JavaScript workers couldn’t directly share memory. Every time I passed an object, it was duplicated, leading to performance bottlenecks.

At this point, I was frustrated. The entire architecture I had designed for my service was based on the assumption that I could efficiently share data between threads. But now, with everything being copied instead of shared, my performance optimizations felt pointless.

That’s when I discovered SharedArrayBuffer.

This completely changed how I viewed JavaScript’s concurrency model. SharedArrayBuffer allowed both the main thread and worker threads to access the same memory block without copying data back and forth. Finally, I had found a way to truly share data between threads.

Excited, I implemented SharedArrayBuffer in my project, mapped it to a TypedArray, and watched as multiple threads accessed the same data. No more unnecessary cloning! It felt like I had unlocked true multi-threading in JavaScript.

But just as I thought I had solved everything, a new problem emerged.

Since multiple threads could modify the shared memory at the same time, I started experiencing race conditions—values would change unpredictably, sometimes disappearing entirely. I quickly realized that JavaScript didn’t have built-in thread synchronization like other multi-threaded languages.

This led me to atomic operations.

With Atomics, I could ensure that when one thread updated a value in shared memory, no other thread would interfere. Implementing this was the final missing piece, and suddenly, everything worked perfectly.

This entire journey completely shattered my original assumptions about JavaScript. It was indeed single-threaded by default, but with the right tools—Web Workers, SharedArrayBuffer, and Atomics—it could achieve true parallel execution just like traditional multi-threaded languages.

Now, whenever someone tells me “JavaScript is single-threaded”, I smile, knowing that while that’s technically true, it’s far from the full story.