Should JavaScript Be Split into Two Languages? Google’s New Proposal Sparks Controversy
By Tim Anderson, translated by Wang Qiang
A Google engineer has submitted a proposalto the official standardization committee that would split JavaScript into two languages: a core language implemented by runtime engines and a more powerful variant language that relies on tools to compileit down to the core language. This proposal was presented at the Emca TC39 meeting earlier this month. TC39 is a committee of Ecma Internationalresponsible for standardizing JavaScript (formally known as ECMAScript).
Shu-yu Guo, a software engineer at Google specializing in JIT, VMs, compilers, and standardization, delivered the presentation. The slides were co-authored by Guoalong with collaborators from Mozilla, Apple, Moddable, and Sony. Moddable is a company that provides open-source SDKs for embedded programming, including the XS JavaScript engine.
The authors argue that the impact of new language features onusers is largely negative. New features almost always reduce security, have a neutral to negative impact on performance, sometimes lead to worse stability, and only improve application functionality when developers use the new features. They state that JavaScript VMs (virtual machines) have become very complex due to speed pressure, which harms security and feels particularly bad when new features are not adopted. They cite examples like the MDN web reference for JavaScript, which has reported engine implementers are investigating whether to remove this feature, and BigInt for large numbers. Regarding BigInt, the presentation points out that use cases never materialized.
According to the proposal,the underlying technology of JavaScript should be simple, as security vulnerabilities and the complexity cost at runtime affect billions of use cases, while the benefits are only enjoyed by developers and applications that can truly utilize this complexity. Despite involving multiple organizations, the plan seems to be driven by Google to some extent, with one slide containingthe disclaimer: This possible solution is Google’s preferred solution, not necessarily the preferred solution of other implementers.
JavaScript developers primarily use compilers based on the new proposal, but some developers wish to move away from this model. The proposed solution is not to roll back existing features or withdraw new features in the later stages ofproposal, but to shift future approaches so that most new features are implemented in tools rather than in JavaScript engines. The engine-implemented language is called JS0, while the tool-implemented language is called JSSugar; these names are for discussion purposes and are not final. The tool concept is particularly suitable forJavaScript.
This proposal has sparked controversy within the JavaScript community. Some developers believe that splitting JavaScript into two languages would create unnecessary complexity and fragmentation. Others argue that it is necessary to address the growing complexity of JavaScript and to ensure that the language remains performant and secure.
The future of JavaScript remains uncertain. It isunclear whether the TC39 committee will accept Google’s proposal. However, the debate over the future of JavaScript is likely to continue, as developers grapple with the challenges of maintaining a language that is both powerful and accessible.
Views: 0