How I built a fast, client-side puzzle solver suite using Next.js and Web Workers

Zero-Cost Serverless Compute: Architecting Heavy Algorithms in the Browser with Web Workers and Bitwise Primitives

Current Situation Analysis

Modern web applications frequently face a binary choice when handling computationally intensive tasks: offload processing to a backend server or risk freezing the user interface by running logic on the main thread. The industry standard has drifted heavily toward server-side computation, driven by the assumption that browsers lack the raw throughput for complex algorithms. This approach introduces latency from network round-trips, creates dependency on backend infrastructure, and incurs variable costs based on compute usage.

However, this paradigm overlooks the capabilities of modern JavaScript engines and the Web Worker API. By isolating heavy computation in background threads and applying low-level algorithmic optimizations, developers can achieve sub-100ms execution times for complex solvers without blocking the UI. This approach eliminates server costs entirely, as the computation leverages the end-user's CPU. The result is a static, globally distributed application that remains responsive regardless of algorithmic complexity, shifting the cost model from operational expenditure to a one-time development investment in optimization.

WOW Moment: Key Findings

The performance and economic implications of moving optimized algorithms to the client are significant. When comparing a traditional server-side solver against a bitwise-optimized Web Worker implementation, the trade-offs shift dramatically in favor of client-side execution for interactive tools.

Metric	Server-Side Solver	Optimized Client-Side Solver
Execution Latency	150ms - 500ms (Network RTT + Compute)	< 100ms (Local CPU only)
Hosting Cost	Variable (Compute cycles per request)	$0 (Static CDN distribution)
UI Responsiveness	Blocked during fetch/parse cycle	Unaffected (Background thread)
Scalability	Limited by server concurrency	Infinite (User device scales)
Data Privacy	Payload transmitted to server	Data never leaves the device

Why this matters: This comparison demonstrates that for algorithmic tools like puzzle solvers, data transformers, or real-time analyzers, client-side execution is not just viable but superior. It enables instant feedback loops for users while reducing infrastructure overhead to zero. The key enabler is not raw browser speed, but the application of bitwise primitives and constraint-based pruning to minimize the computational surface area.

Core Solution

Building a high-performance client-side solver suite requires a three-pillar architecture: thread isolation, bitwise data representation, and algorithmic pruning.

1. Thread Isolation with Web Workers

The main thread must remain dedicated to rendering and event handling. All solver logic is encapsulated in a Web Worker. In a Next.js environment, this requires dynamic imports to prevent server-side execution errors.

Architecture Decision: Use a typed message bridge to ensure type safety between the React component and the worker. This prevents serialization errors and makes refactoring safer.

// worker/bridge.ts
// A typed wrapper around postMessage to handle async solver calls
export class SolverBridge {
  private worker: Worker;
  private pendingRequests = new Map<string, { resolve: Function; reject: Function }>();

  constructor(workerPath: string) {
    this.worker = new Worker(workerPath, { type: 'module' });
    this.worker.onmessage = this.handleMessage.bind(this);
  }

  private handleMessage(event: MessageEvent) {
    const { id, result, error } = event.data;
    const request = this.pendingRequests.get(id);
    if (request) {
      if (error) request.reject(new Error(error));
      else request.resolve(result);
      this.pendingRequests.delete(id);
    }
  }

  solve<T, R>(type: string, payload: T): Promise<R> {
    return new Promise((resolve, reject) => {
      const id = crypto.randomUUID();
      this.pendingRequests.set(id, { resolve, reject });
      this.worker.postMessage({ id, type, payload });
    });
  }

  terminate() {
    this.worker.terminate();
  }
}

2. Bitwise Board Representation

For grid-based puzzles, 2D arrays introduce overhead due to pointer chasing and iteration. Representing rows as integers allows parallel evaluation of cell states using bitwise operators. This reduces row checks from O(N) to O(1).

Implementation: The BitboardEngine uses 32-bit integers for rows. Note that JavaScript bitwise operators work on signed 32-bit integers; for larger grids, BigInt or split-word strategies are required.

// solvers/bitboard-engine.ts
export class BitboardEngine {
  private rows: number[];
  private cols: number[];
  private width: number;
  private height: number;

  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
    this.rows = new Array(height).fill(0);
    this.cols = new Array(width).fill(0);
  }

  // Check if a block fits at (r, c) with shape mask
  canPlace(r: number, c: number, shapeMask: number): boolean {
    if (r < 0 || c < 0 || r + shapeMask.length > this.height) return false;
    
    for (let i = 0; i < shapeMask.length; i++) {
      const rowMask = shapeMask[i] << c;
      // Bitwise AND detects overlap: if (existing & new) !== 0, collision exists
      if ((this.rows[r + i] & rowMask) !== 0) return false;
    }
    return true;
  }

  placeBlock(r: number, c: number, shapeMask: number): void {
    for (let i = 0; i < shapeMask.length; i++) {
      const rowMask = shapeMask[i] << c;
      // Bitwise OR sets the bits
      this.rows[r + i] |= rowMask;
    }
  }

  // Clear full rows and return count
  clearFullRows(): number {
    let cleared = 0;
    const fullRowMask = (1 << this.width) - 1;
    
    for (let r = 0; r < this.height; r++) {
      if (this.rows[r] === fullRowMask) {
        this.rows[r] = 0;
        cleared++;
      }
    }
    return cleared;
  }
}

3. Trie-Based Dictionary Search

For word search solvers, scanning every path in the grid is computationally expensive. A Trie (prefix tree) allows immediate pruning of invalid paths. If the current character sequence does not exist as a prefix in the dictionary, the search branch is terminated instantly.

Implementation: The PrefixTree supports insertion and prefix validation. The solver traverses the grid in 8 directions, querying the Trie at each step.

// solvers/prefix-tree.ts
interface TrieNode {
  children: Map<string, TrieNode>;
  isEndOfWord: boolean;
  word?: string;
}

export class PrefixTree {
  private root: TrieNode;

  constructor() {
    this.root = { children: new Map(), isEndOfWord: false };
  }

  insert(word: string): void {
    let node = this.root;
    for (const char of word) {
      if (!node.children.has(char)) {
        node.children.set(char, { children: new Map(), isEndOfWord: false });
      }
      node = node.children.get(char)!;
    }
    node.isEndOfWord = true;
    node.word = word;
  }

  hasPrefix(prefix: string): boolean {
    let node = this.root;
    for (const char of prefix) {
      if (!node.children.has(char)) return false;
      node = node.children.get(char)!;
    }
    return true;
  }

  getRoot(): TrieNode {
    return this.root;
  }
}

4. Constraint Satisfaction for Nonograms

Nonogram solvers benefit from a hybrid approach. Pure backtracking is too slow for large grids. Instead, apply line-solving heuristics to pre-fill cells based on clue intersections and spacing constraints. Only when heuristics stall should the solver fall back to depth-first search (DFS) on the remaining ambiguous cells.

Implementation: The ConstraintSolver propagates constraints across rows and columns. This reduces the search space exponentially before DFS begins.

// solvers/constraint-solver.ts
export class ConstraintSolver {
  private grid: number[][]; // 0: unknown, 1: filled, -1: empty
  private rowClues: number[][];
  private colClues: number[][];

  constructor(rows: number, cols: number, rowClues: number[][], colClues: number[][]) {
    this.grid = Array.from({ length: rows }, () => Array(cols).fill(0));
    this.rowClues = rowClues;
    this.colClues = colClues;
  }

  // Apply heuristics to reduce unknown cells
  propagateConstraints(): boolean {
    let changed = true;
    let stable = false;

    while (changed) {
      changed = false;
      // Solve rows
      for (let r = 0; r < this.grid.length; r++) {
        const solved = this.solveLine(this.grid[r], this.rowClues[r]);
        if (solved) changed = true;
      }
      // Solve columns
      for (let c = 0; c < this.grid[0].length; c++) {
        const col = this.grid.map(row => row[c]);
        const solved = this.solveLine(col, this.colClues[c]);
        if (solved) {
          // Write back to grid
          for (let r = 0; r < this.grid.length; r++) {
            this.grid[r][c] = col[r];
          }
          changed = true;
        }
      }
      stable = !changed;
    }
    return stable;
  }

  private solveLine(line: number[], clues: number[]): boolean {
    // Heuristic logic: calculate valid permutations for the line
    // Intersect permutations to find cells that are always filled or always empty
    // Update line array and return true if any cell changed from 0 to 1/-1
    // Implementation details omitted for brevity, but involves combinatorial intersection
    return false; 
  }
}

Pitfall Guide

1. 32-Bit Integer Limitation in Bitwise Ops

   • Explanation: JavaScript bitwise operators coerce operands to signed 32-bit integers. Grids wider than 31 columns will cause data corruption or sign extension issues.
   • Fix: Use BigInt for bitwise operations on larger grids, or split the row into multiple 32-bit words and manage carry logic manually.

2. Serialization Overhead in Workers

   • Explanation: Passing large objects between the main thread and worker triggers structured cloning, which can block the main thread and consume memory.
   • Fix: Minimize payload size. Send only deltas or indices. Use Transferable objects (like ArrayBuffer) for large binary data to move ownership rather than copy.

3. Worker Lifecycle Mismanagement

   • Explanation: Creating a new Worker instance for every solver call incurs significant startup latency and memory overhead.
   • Fix: Instantiate a single Worker per feature and reuse it. Implement a message queue within the worker if concurrent requests are possible, or serialize requests from the main thread.

4. Algorithmic Regression via Micro-Optimization

   • Explanation: Optimizing bitwise operations is useless if the underlying algorithm has exponential complexity. A poorly designed solver will still time out regardless of bit manipulation.
   • Fix: Profile algorithmic complexity first. Apply pruning, heuristics, and memoization before optimizing data structures. Bitwise ops amplify efficiency; they do not fix bad Big-O.

5. Next.js Static Export Conflicts

   • Explanation: Web Workers rely on browser APIs (window, Worker) that are undefined during server-side rendering or static generation.
   • Fix: Use next/dynamic with { ssr: false } to load worker-dependent components. Ensure worker files are excluded from the server bundle via next.config.js externals or path aliases.

6. Memory Leaks in Closures

   • Explanation: Workers can retain references to large datasets in closures, preventing garbage collection. This is critical in long-running single-page applications.
   • Fix: Explicitly nullify references after solving. Use WeakMap for caching if appropriate. Monitor worker memory usage via browser dev tools.

7. Ignoring User Device Variance

   • Explanation: Client-side compute assumes a baseline CPU capability. Low-end mobile devices may struggle with complex solvers, leading to poor UX.
   • Fix: Implement adaptive complexity. Detect device performance capabilities and reduce search depth or heuristic iterations for lower-tier devices. Provide progress feedback for longer operations.

Production Bundle

Action Checklist

• Isolate Solver Logic: Move all algorithmic code into a dedicated worker/ directory with no UI dependencies.
• Implement Bitboard Representation: Replace 2D arrays with integer masks for grid-based puzzles; verify width limits.
• Build Trie Dictionary: Pre-load word lists into a Trie structure to enable O(1) prefix checks during grid traversal.
• Add Constraint Propagation: Implement heuristic solvers for logic puzzles to reduce DFS search space before backtracking.
• Configure Next.js Worker: Set up next.config.js to handle worker bundling and use next/dynamic for client-only imports.
• Benchmark Execution: Use performance.now() inside the worker to verify sub-100ms solve times on target hardware.
• Test Serialization: Audit message payloads between main thread and worker to ensure minimal data transfer.
• Deploy Static Export: Run next export and verify the application runs entirely from static assets with zero server compute.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Interactive Puzzle Tool	Client-Side Worker + Bitwise	Instant feedback required; no server latency; $0 hosting.	$0 Infrastructure
Large Dataset Analysis	Server-Side Compute	Client memory limits; heavy I/O; privacy concerns.	Variable Compute Cost
Real-Time Collaboration	Hybrid (Server State + Client Preview)	Server maintains source of truth; client handles local rendering.	Moderate Server Cost
Mobile-First Audience	Adaptive Client-Side	Reduce complexity for low-end devices; avoid network dependency.	$0 Infrastructure

Configuration Template

next.config.js Configure Next.js to support static export and handle worker files correctly.

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  // Ensure worker files are not processed as server modules
  webpack: (config) => {
    config.resolve.fallback = {
      ...config.resolve.fallback,
      fs: false,
      path: false,
    };
    return config;
  },
  // Optional: Copy worker files to public folder if using raw Worker constructor
  // This depends on your build setup; ensure worker.js is accessible at runtime.
};

module.exports = nextConfig;

components/SolverPanel.tsx Dynamic import pattern to prevent SSR issues.

import dynamic from 'next/dynamic';

const SolverPanel = dynamic(() => import('./SolverPanel.client'), {
  ssr: false,
  loading: () => <div>Initializing solver engine...</div>,
});

export default SolverPanel;

Quick Start Guide

1. Initialize Project: Run npx create-next-app@latest puzzle-solver --typescript.
2. Add Worker: Create worker/solver.worker.ts and implement the BitboardEngine or PrefixTree logic.
3. Bridge Setup: Create worker/bridge.ts with the SolverBridge class to manage async communication.
4. UI Integration: In a client component, instantiate SolverBridge, pass grid data, and await results. Update state on resolution.
5. Export & Deploy: Run npm run build and npm run export. Deploy the out/ directory to any static CDN (Vercel, Netlify, Cloudflare Pages) for zero-cost hosting.