Should JavaScript be split into two languages?

Original Article ↗ Hacker News Discussion ↗

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.