ADR-008 — Lambert solver in Web Worker

Status · Accepted Date · 2026-04-01 TA anchor · §components/lambert-worker · §constraints

Context

The porkchop plot requires computing 11,200 Lambert solutions (112 departure × 100 arrival date combinations). Each solution requires an iterative solver. Running this on the main thread blocks the UI for several seconds on slow hardware.

Decision

The Lambert solver runs in a dedicated Web Worker (src/workers/lambert.worker.js). The main thread posts a message with the date range and step counts; the worker computes the full grid and posts back the result.

Rationale

The Lambert computation is pure — no DOM access, no state mutation, no shared memory required. Web Workers are the correct tool. The main thread remains responsive (animations continue, user can interact with the nav) while the computation runs.

Alternatives considered

• Main thread computation — simplest implementation; blocks UI for 1-3 seconds on first load of plan screen. Unacceptable.
• WASM solver — faster computation; adds build complexity and a WASM dependency. Not needed; the JS solver is fast enough in a worker.
• Precompute at build time — bakes in a fixed date range; can't support arbitrary user-selected ranges.

Consequences

Positive: main thread stays responsive; solver can be cancelled and restarted if user changes date range. Negative: Worker message passing adds complexity; error handling across Worker boundary requires care. See RFC-003 for open questions.