Skeptical of rewriting JavaScript tools in "faster" languages

Original Article ↗ Hacker News Discussion ↗

Calls to rewrite JavaScript tooling in faster languages like Rust, Go or Zig are provoking a split between those who prize raw performance and those who value debuggability, extensibility and a single-language toolchain. Proponents of rewrites point to dramatic speedups, better parallelism and stronger type systems, especially for AST-heavy tasks like bundling, linting and formatting; skeptics counter that many problems stem from poor algorithms and convoluted JS tooling rather than the language itself, and worry about raising the barrier for everyday web developers. The exchange also touches on WebAssembly’s role, the limits of JIT optimizations, and a broader question of whether ecosystem simplicity and accessibility should sometimes outweigh maximum throughput for build and CLI tools.

Performance of JS vs “faster” languages

  • Many commenters report large real‑world speedups (often 8–10x, sometimes more) when rewriting Python/JS tools in Rust/Go/C++/Go, even with similar algorithms.
  • Others argue rewrites often bundle better algorithms, data structures, and reduced cruft, so language isn’t the only cause.
  • Several note JS/V8 can be surprisingly fast and sometimes within an order of magnitude of C/C++, but say its startup time, GC, hidden allocations, and weaker SIMD/memory control make it a poor fit for tight, low‑latency tooling and heavy AST/string work.
  • Some say: if you care enough about asymptotic complexity to micro‑optimize, you probably shouldn’t be in a slow dynamic language for that part anyway.

Tooling, ecosystem, and DX

  • JS tooling (webpack, Babel, Node ecosystem) is widely described as complex, brittle, and slow; build‑tool rewrites (esbuild, SWC, Rspack, Ruff, uv) are cited as night‑and‑day improvements.
  • Others stress that JS’s huge ecosystem, hot‑reload, and instant edit–run loops make it highly productive; AOT languages pay in compile times.
  • Several distinguish “JS” from “Node”: many pain points are Node/npm/package‑tree issues, not the language spec itself.

Debuggability, extensibility, and accessibility

  • A key argument for JS tools: everything is in one language; devs can monkey‑patch node_modules, debug with console.log, and write plugins easily.
  • Concern: native/wasm tools raise the bar—checking out, compiling, and understanding Rust/Go/C++ is harder, especially for juniors; fewer people will patch or extend the tooling.
  • Counterpoint: most devs never fix their JS tooling anyway, and many CLI users actively prefer not to depend on Node at all.

Types and language design

  • Strong divide over JS’s “forgiving” dynamic typing:
    • Supporters value speed of iteration, duck typing, and incremental typing (e.g., TypeScript, Python type hints) as code matures.
    • Critics call weak/implicit coercions and null/undefined duality major footguns; see static typing as essential for correctness and maintainability.
  • Rust’s type system and safety are praised for tooling, but some see its learning curve as a poor fit for “working‑class” tooling that many web devs might need to hack on.

Parallelism and scalability

  • Several note that language‑tool workloads (parsing, linting, formatting, bundling) are often embarrassingly parallel.
  • Rust/Go libraries (e.g., Rayon‑style patterns) make parallelism simple and safe; JS workers are seen as clunky, with higher overhead and weaker shared‑memory models.

WebAssembly and future directions

  • Some predict JS apps will gradually offload performance‑critical parts to WebAssembly, eventually shifting much logic to non‑JS languages.
  • Others push back: current wasm+canvas UIs struggle with a11y, text selection, OS integration, and real‑world performance on some devices; DOM‑based UIs and JS remain dominant.
  • There is interest in wasm as a portable, sandboxed target for server and client, but disagreement on when it truly beats native or JS in practice.