I've been building a Sokoban editor and solver for tilebasedworlds.com — a side project for tile-based puzzle tools. The solver ships entirely in the browser as a WASM binary, which meant the first real question was not "how do I implement A*?" but "how do I represent a level?" That choice turns out to propagate through every part of the solver, the URL format, and the state-space design. The answer I landed on was bitplanes.
Read more →In the previous article I described a path from dynamic languages toward TypeScript, and from TypeScript toward stricter compiled languages. Rust is the end of that path — but it took some convincing to get there, and the thing that convinced me wasn't the systems programming story. It was the frontend.
TypeScript is an extraordinary tool within its constraints. The type system is expressive, the ecosystem is vast, and the developer experience — particularly with modern tooling — is genuinely good. But TypeScript erases at runtime. The types you write are a compile-time overlay on JavaScript; they do not exist when the code executes. The compiler can tell you when your model is inconsistent, but it cannot prevent every class of runtime failure.
Read more →The WebAssembly ecosystem has accumulated a solid set of command-line tools that don’t get surfaced well in most introductory material. Tutorials tend to focus on one language path — Rust via wasm-pack, or Go, or Emscripten — and leave the broader toolchain unexplained. This is a reference for the tools I reach for regularly: inspection, compilation, optimisation, and runtimes.
Before the tools: WASM has two representations. The binary format (.wasm) is what the runtime executes. The text format (.wat) is human-readable S-expression syntax — the assembly language of WebAssembly. Understanding WAT is useful for debugging and for writing minimal WASM by hand.