JavaScript Is Becoming 2 Languages?? FROM TC39
Based on The PrimeTime's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
TC39 is considering splitting JavaScript into an engine-implemented core (JS0) and tool-compiled syntax extensions (JS sugar).
Briefing
TC39 is considering a split of JavaScript into two layers: a “JS0” core implemented directly by engines, and “JS sugar” syntax features that must be compiled by tools into JS0. The proposal, associated with a Google agenda item, aims to keep engines from being forced to support every new syntax addition immediately—especially when those additions create performance and security burdens for implementers. In practice, it would formalize what developers already do informally: TypeScript and other toolchains compile extended syntax into plain JavaScript that engines can run.
Supporters frame the split as a way to let language features evolve faster at the developer level while engines adopt changes more gradually. That matters because modern JavaScript development is heavily mediated by tooling—bundlers, transpilers, and frameworks—so the “authoring language” often differs from the “runtime language.” The discussion also ties into a broader theme: new syntax and abstractions can improve developer productivity, but they can also complicate engine internals, increase the risk surface for security issues, and create debugging challenges when features expand into many lower-level operations.
Critics in the conversation argue that the ecosystem already struggles with tooling complexity and that adding another layer of standardization may not reduce pain. They point out that JavaScript’s current reality includes heavy compilation and transformation, yet developers still face issues like source-map mismatches, code bloat, and hard-to-debug behavior when high-level features desugar into large chunks of generated code. Pattern matching is used as an example of a feature that could be “cool” but also potentially expensive to implement efficiently and safely inside engines.
The discussion then pivots to a related “systems” point: performance and transport efficiency in the web stack. HTTP/3 is contrasted with HTTP/2, focusing on how the transport mechanism changes the reliability model. HTTP/2 relies on TCP and uses mechanisms like HPACK for header compression, while HTTP/3 runs over QUIC (UDP-based), avoiding TCP’s acknowledgement-driven sliding window behavior. The practical takeaway is that reducing protocol-level waiting can improve throughput, but it shifts responsibility for loss handling to the application/transport layer.
Finally, the conversation returns to the language-evolution process and the stakeholders involved—developers, implementers (including engine teams), and users. The proposed “JS0 + JS sugar” taxonomy is presented as an attempt to align incentives: engines prioritize security, performance, and stability; developers want expressive features and better mental models; and users ultimately care about reliability and speed. The central tension remains unresolved: whether formalizing compilation layers will genuinely reduce complexity for developers and users, or simply reorganize the existing “mess” into a more standardized pipeline (TypeScript and other stages potentially becoming “TS sugar” feeding into JS sugar, then down to JS0).
Cornell Notes
TC39 is weighing a two-tier JavaScript model: a “JS0” core that engines implement, plus “JS sugar” syntax that tools compile into JS0. The goal is to prevent every new developer-facing feature from immediately forcing engine changes that can raise performance and security costs. The conversation notes that this largely formalizes today’s reality, where TypeScript and other toolchains already transpile extended syntax into engine-compatible JavaScript. The main concern is that more layers could worsen code bloat and debugging complexity when high-level operations expand into many lower-level steps. The proposal is framed as an incentive alignment problem: engines optimize for stability, while developers want faster feature evolution and better expressiveness.
What does the proposed “JS0 vs JS sugar” split try to solve, and why does it matter for engines?
How is the proposal connected to what developers already do with TypeScript and bundlers?
Why do critics worry that more compilation layers could make debugging harder?
What example feature is used to illustrate both developer appeal and engine burden?
How does the HTTP/2 vs HTTP/3 discussion reinforce the theme of shifting responsibilities between layers?
What does the “stakeholders” framing add to the language-evolution debate?
Review Questions
- If JS sugar features compile into JS0, what kinds of problems could still arise even if engines become simpler?
- How do TCP’s acknowledgement and sliding-window behavior differ from QUIC’s UDP-based approach, and what does that imply for performance?
- What incentive mismatch does the JS0/JS sugar proposal attempt to address among engines, developers, and users?
Key Points
- 1
TC39 is considering splitting JavaScript into an engine-implemented core (JS0) and tool-compiled syntax extensions (JS sugar).
- 2
The split is motivated by performance and security burdens that new syntax can impose on engine implementers.
- 3
The proposal largely formalizes existing practice where TypeScript and other toolchains transpile extended syntax into engine-compatible JavaScript.
- 4
A major risk is that transpilation can create code bloat and make debugging harder when one high-level operation expands into many lower-level steps.
- 5
The discussion ties language evolution to incentive alignment: engines optimize for stability while developers want faster feature evolution and better expressiveness.
- 6
The HTTP/2 vs HTTP/3 segment illustrates how changing transport mechanisms shifts reliability and performance tradeoffs between layers (TCP/ACKs vs QUIC/UDP).
- 7
The ecosystem concern remains whether standardizing more compilation stages will reduce complexity or simply reorganize an already complicated toolchain pipeline.