How I stopped a local chess engine from freezing the browser UI

When building browser-based tools that handle heavy computation—like a chess engine calculating deep positional variations—running everything on the main JavaScript thread is a recipe for disaster. The moment the engine starts thinking, the entire UI locks up. Users can't click buttons, drag pieces, or even scroll.

To solve this for a personal project, I isolated the UI state from the raw processing by offloading the entire Stockfish engine execution to a Web Worker.

The Setup

The visual board runs smoothly on the main thread, while the engine calculations run entirely in the background. They communicate asynchronously via simple message passing:

1. The user moves a piece on the board.
2. The main thread captures the new position and sends the updated FEN string to the Web Worker via worker.postMessage().
3. The Worker computes the engine evaluation lines in the background without touching the DOM.
4. The Worker streams the live evaluations back to the main thread using postMessage(), which instantly updates a lightweight evaluation bar.

This completely eliminates main-thread blocking. You can flip the board, toggle settings, and interact with the UI flawlessly even while a depth-20 calculation is running in the background.

I implemented this exact setup in a lightweight, serverless chess utility I've been polishing. If you want to check out how smooth the client-side evaluation handles, or inspect the network tab to see it running 100% locally with zero backend requests, you can play around with it here:

👉 CipherKit Chess Board Analyzer

How are you guys handling heavy local computations or WASM/Worker state management in vanilla JS architectures lately? Let's discuss in the comments!