JavaScript might become two languages (and it's dramatic)

What is the JS Sugar and JS Zero proposal?

The JS Sugar and JS Zero proposal aims to split JavaScript into two distinct parts. This innovative proposal suggests one part, called JS Zero, would be implemented by JavaScript engines themselves, maintaining the core of the language. The other part, known as JS Sugar, would handle new features through build tools, leaving the updates to compilers like Babel.

The rationale behind this idea is to address concerns about the complexity developers face due to the evolving nature of JavaScript. By offloading new feature implementations to build tools, browser developers can focus on performance, security, and stability without the burden of constant language changes.

JS Sugar and JS Zero propose a new methodology for introducing language features. Instead of making all new features part of JavaScript engines, they would primarily be part of the external tools. This change suggests a shift in responsibility and complexity from browser implementers to the developers of build tools.

How could the proposal change JavaScript development?

• Role of Build Tools: Build tools like Babel and Webpack may become more essential. New features of JavaScript could be handled entirely through these tools, making them indispensable for coding.

• Impact on Vanilla JavaScript: Vanilla JavaScript may face a significant decline. The shift towards relying on tools would mean that pure JavaScript without additional tooling might become obsolete.

• Implications for Developers: Developers could experience increased complexity. Understanding both JS Sugar and JS Zero might require adapting workflows to include robust build tools consistently.

• Browser and Engine Adjustments: Browsers might not need to adopt every new feature natively. They could focus instead on core performance, security, and stability, while build tools tackle new syntax.

This shift proposes a major transformation in the JavaScript ecosystem, potentially affecting how developers interact with modern bundling technologies like NPM. These changes may redefine the roles of developers, browsers, and build tools significantly.

What are the arguments for and against the proposal?

The JavaScript Sugar and Zero proposal has sparked a lively debate. Some see it as a potential evolution, while others warn of its risks.

In favor, proponents argue that shifting complexity to build tools could streamline browser development. Fewer updates in core engines might improve security, performance, and stability.

However, detractors raise significant concerns. Brendan Eich, the creator of JavaScript, emphasizes the danger of implementers dictating terms without real web development experience. He states,

"Implementers should not be calling the shots."

He fears this could disconnect them from practical needs.

Others worry about the increased burden on tool authors. One community member notes,

"JS tooling does not have the resources to deal with this."

The complexity might surpass current capacities, leading to a fragmented ecosystem. This split could fundamentally alter how JavaScript features get adopted, potentially sidelining essential updates. The community remains divided on whether the proposal offers enough benefits to developers and users alike.

What does this mean for the future of JavaScript?

The proposal to split JavaScript into JS Sugar and JS Zero has profound implications for its future. It poses potential challenges in both implementation and learning curves. Developers will face the task of mastering a new workflow, balancing between JavaScript Sugar for innovative features and JavaScript Zero for engine compatibility.

Opportunities arise in the form of more streamlined browser development. By shifting complexities to build tools, browser engines can focus on optimizing for speed and security. This separation could allow for more stable and efficient browser experiences.

Tooling authors might see a surge in demand as build tools become integral to JavaScript development. This brings both opportunity and pressure to adapt swiftly to new standards. However, the risk of fragmenting the ecosystem looms large, with developers potentially relying on diverse toolchains for functionality.

Overall, while the proposal carries significant promise, it also demands a careful evaluation of its impact on the JavaScript ecosystem. The community must weigh the benefits against potential complexities to ensure a thriving developer experience.