Skeptical of rewriting JavaScript tools in "faster" languages

Original Article ↗ Hacker News Discussion ↗

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.