Should JavaScript be split into two languages?

Original Article ↗ Hacker News Discussion ↗

A new proposal backed by several browser vendors would split JavaScript into a small, stable “core” language (JS0) and an optional higher‑level layer that compiles down to it, aiming to make engines faster and more secure. Commenters are sharply divided: supporters like the idea of reducing VM complexity and pushing most new features into tooling, while critics fear increased fragmentation, heavier build pipelines, and a loss of hard‑won progress toward writing modern JS without transpilers. Many argue that efforts would be better spent on WebAssembly and richer browser APIs—or on deprecating little‑used language features—rather than redefining JavaScript’s evolution model.

Split JS into core vs. sugar

  • Many argue JS is already effectively two things: a low‑level “assembly of the web” and a high‑level front‑end language compiled from TS/JSX/etc.
  • Supporters of the proposal like the idea of freezing a small, stable core and pushing new “nice but complex” features into a compiled layer.
  • Critics fear this entrenches tooling dependence, shifts complexity from browsers to toolchains, and could stall native language evolution.

Tooling, transpilation, and debugging

  • Some say modern source maps and framework devtools make transpiled code no harder to debug than native ES.
  • Others dislike that “the code running isn’t what I wrote” and note many sites don’t ship source maps or offer seamless step‑through debugging.
  • There is disagreement on whether tooling overhead is now a solved cost of doing front‑end work or an unnecessary burden.

WebAssembly as the “real” JS0

  • A large subthread argues “JS0 should just be WebAssembly,” letting any language target the web and relegating JS to scripting.
  • Examples are cited of significant performance wins from migrating parts of apps to WASM.
  • Counterpoints: WASM bundles are often large, many don’t want a compile step, and JS engines are already extremely fast.

DOM access, GC, and WASM limitations

  • Repeated complaints that WASM lacks direct, ergonomic DOM access and previously promised features (like richer JS object interop) are delayed.
  • Others respond that DOM access is technically possible today via JS “glue” imports; the debate is about ergonomics and performance, not raw capability.
  • WASM GC exists in most browsers, but some languages still need more features; string and object interop remain contentious.

Fragmentation, compatibility, and ecosystem fatigue

  • Several worry that formalizing JS0/JSSugar would explode into many incompatible “JS dialects,” mirroring existing fragmentation (TS, JSX, Svelte, etc.).
  • Others argue this is already reality and standardizing a core could at least bound what engines must support.
  • Framework churn, shifting “best practices,” and management‑driven rewrites are cited as a major source of developer exhaustion.

Language features, BigInt, and desired direction

  • Many push back on the claim that BigInt “never found use cases,” citing everyday backend and crypto/hashing usage.
  • Some want fewer new features and more work on browser APIs, performance, and parity with native apps.
  • Others would still like a few big additions (value types/structs, pattern matching) and then a long language freeze.

VM complexity, security, and alternative VMs

  • Some sympathize that JS VMs are hard to keep fast and secure, but see this proposal as offloading vendor maintenance problems onto developers.
  • There’s discussion of why existing bytecode VMs (JVM, CLR, LLVM IR) weren’t used for the web; sandboxing, politics, and C/C++ compatibility are cited.
  • A recurring theme: browsers are de facto OS‑like runtimes, and any change to JS/WASM must consider global scale, security, and bandwidth costs.