Tree-shaking, the horticulturally misguided algorithm (2023)

Original Article ↗ Hacker News Discussion ↗

Tree-shaking vs. Dead Code Elimination (DCE)

  • Strong debate over terminology. Some argue “tree-shaking” is a confusing misnomer and that “dead code elimination” or “reachability analysis” are clearer, long‑established terms.
  • Others defend “tree-shaking” as evocative, widely adopted (especially in JS), and semantically distinct: often used for bundler‑level, inter‑module pruning based on dependency graphs, while “DCE” is used for compiler/engine‑level, often intra‑function optimizations.
  • Historical notes: early “treeshakers” in Lisp (and possibly Smalltalk) operated on whole images, removing unused code and data, not just functions. Some argue this broader scope justifies a distinct term.
  • Several commenters insist the operations are conceptually the same; others maintain that granularity and tooling differences justify two names.

Wasm Code Size and Practical Optimization

  • Consensus that Wasm often suffers from large code size, problematic for initial page load and serverless cold starts.
  • Techniques reported to reduce size (mostly in Rust/Wasm):
    • Avoid floats, HashMaps, and strings when possible; use fixed point and vectors.
    • Minimize generic type diversity to avoid monomorphization bloat.
    • Use small allocators and strict size‑oriented compiler settings (e.g., opt-level="z", LTO, single codegen unit).
    • Post-process with wasm-opt and serve with Brotli compression.
  • Some think shrinking from ~700KB to ~400KB is only marginally useful on the web; others see it as an important counterexample to perceptions that Wasm apps are inevitably bloated.
  • Rust’s formatting/dbg! and standard library can inject surprising size overhead. WasmGC is seen as a way to cut runtime/allocator bulk, with current best results cited for Java/Kotlin.

Dynamic Linking and Shared Runtimes

  • Proposed long‑term fix: treat language runtimes as dynamically linked Wasm modules shared across apps.
  • Example: a single Pyodide runtime can be shared across many serverless workers.
  • Vision: browsers (or platforms) pre‑load popular runtimes/libraries so individual apps don’t ship them each time.
  • Concerns raised:
    • Cache partitioning and fingerprinting/privacy issues.
    • Version explosion and ABI stability; would require strong backward compatibility or curated, limited sets of versions.
    • Governance questions over which runtimes get “blessed” and preloaded.
  • Ideas floated: profile‑guided tree‑shaking plus on‑demand downloading of rarely used code, but risk of missing rare paths is noted.

Wasm, DOM Access, and GUI Models

  • Current reality: DOM and Web APIs are exposed to JS, so Wasm typically calls through JS “glue.” GC‑based references (WasmGC, component model) are expected to make direct DOM interaction more feasible.
  • Some argue that bypassing DOM/JS to render entirely via canvas/WebGL/WebGPU (for “native‑style” apps) is attractive; others counter this sacrifices accessibility and browser‑provided UI primitives, effectively “building a browser inside the browser.”
  • There is disagreement over whether Wasm should mainly supplement JS (e.g., heavy compute, workers) or be a full replacement for JS in front‑end development.

Wider Role and Design of Wasm

  • One camp sees Wasm as a deliberately minimal, secure, capability‑based “MVP” ISA, expected to grow features (GC, better host bindings).
  • Another camp finds it underpowered compared to classic VMs (no built‑in GC/stdlib or trivial DOM hooks), questioning its value for general web apps and some edge/FaaS scenarios.
  • Despite skepticism, multiple real uses are cited (games, RL libraries, map/earth viewers, Blazor, Flutter font/icon shaking), and some languages (e.g., OCaml, Zig) are viewed as promising for ultra‑small Wasm outputs.