← All posts

Fast Client-Side Puzzle Solvers with Next.js and Web Workers

Next.js static export, Web Workers for heavy algorithms, bitboards for Block Blast, trie for word search — $0 hosting.

Fast Client-Side Puzzle Solvers with Next.js and Web Workers
Contents

In brief

The author built puzzletoolbox.com — a suite of puzzle solvers on Next.js static export with compute in Web Workers. The UI stays smooth while a background thread crunches millions of permutations. Bitboards, tries, and heuristics keep answers under 100 ms; hosting costs $0 because the client pays for CPU.

What happened

The goal was fast solvers for Block Blast, Nonograms, and Word Search without server-side compute. Next.js ships as a static export via CDN; heavy work moves to a Web Worker so the main thread never blocks animations, input, or layout.

For speed, naive 2D arrays were dropped where it mattered:

  • Block Blast — board state as a bitboard (integer bit mask). Checking whether a block fits and clearing a row become AND/OR operations instead of grid walks.
  • Nonograms — constraint satisfaction with line-solving heuristics (intersections, spacing) before falling back to DFS; the search space shrinks exponentially.
  • Word Search — a Trie (prefix tree): when scanning the grid in eight directions, discard paths whose character sequence is not a valid dictionary prefix.

The result is a live tool at https://puzzletoolbox.com where latency is set by algorithms on the user’s device, not an API round-trip.

Why it matters

The pattern of 100% client-side compute changes the economics of side projects and interactive utilities:

  • No server bill for CPU — only CDN for static assets.
  • Scale with users does not require autoscaling backend.
  • Web Workers are the standard way to keep UX smooth under heavy browser logic.

The lesson is not “everything in JS” but choosing data structures for the domain: bitboards for grid puzzles, trie for prefix search, heuristics before brute force. Raw array manipulation over millions of permutations will not fit an interactive budget.

Next.js static export here is a deliberate tradeoff: no SSR/API routes in production, but global CDN and predictable cost.

In practice

If you build a similar browser-based solver or simulator:

  1. Move search into a Worker with a clear message protocol (board state in, best move out).
  2. For grid tasks, evaluate bitboards — often an order-of-magnitude speedup without WASM.
  3. For dictionary search, build a Trie once at load time, not a linear scan over words.
  4. Deploy as static export + CDN; profile on low-end mobile, not only on an M-series Mac.

State sync between Worker and React needs care — but for read-heavy solvers it is simpler than optimistic UI in multiplayer.

Takeaway

A client-side puzzle suite on Next.js and Web Workers is a case where algorithms and thread isolation matter more than backend stack. Bitboards and tries keep latency low and static hosting free. Read the original if you design interactive utilities without server compute.