A Google engineer presented a proposal to the official standardization committee that would split JavaScript into two languages, a core to be implemented by runtime engines and a more capable variant which depends on tools that compile it down to that core.

The presentation was at a meeting of Emca TC39 earlier this month, TC39 [https://tc39.es] being the committee of Ecma International that evolves the JavaScript (officially ECMAScript) specifiation.

Shu-yu Guo, a staff software engineer at Google who specializes in JITs, VMs, compilers and standardization, made the presentation, with slides that were co-authored by Guo along with others from Mozilla, Apple, Moddable and Sony. Moddable is a company which offers an open source SDK for embedded programming, including the XS JavaScript engine.

The authors argue that new language features have a mostly negative impact on users. New features “almost always” worsen security, performance is “neutral to negatively impacted,” stability is sometimes worse, and app features are only improved if developers use what is new.

JavaScript VMs (virtual machines), they say, are “already very complex because of pressure to be fast,” which compromises security, and “feels especially bad” when new features do not get adoption. They cite species, where the MDN web reference for JavaScript already reports that “engine implementers are investigating whether to remove this feature,” and BigInt, for large numeric values. Regarding BigInt, the presentation states that “use cases never materialized.”

The foundational technology of JavaScript should be simple, according to the proposal, because security flaws and the “complexity cost” of the runtimes affects billions of uses, whereas the benefits are restricted to developers and applications that actually use that complexity to advantage.

Despite the multiple organizations involved, the initiative seems to be driven by Google to some extent, and one of the slides contains a disclaimer that “this possible solution is Google’s preferred solution, not necessarily other implementers’”

The proposed solution is not to backtrack on existing features, including new ones where proposals are at a late stage, but to change the future approach to one where most new features are implemented in tooling rather than in the JavaScript engines. The language implemented by the engines is called “JS0” while the language implemented by the tooling is “JSSugar”; these names are used to enable discussion and not intended as final.

The tooling idea is particularly appropriate for JavaScript since many developers actually code in TypeScript and rely on compilers such as Babel, Webpack or the TypeScript compiler to output JavaScript. From the developer perspective, JavaScript is JSSugar, but the runtime engines need only implement JS0. The implication is that there should be more standards compliance among tools.

If adopted, the proposal would mean that future syntax features go into JSSugar, and only API and capability features go into JS0. Compliant engines would only need to support JS0. The burden would shift to tool implementers to support JSSugar, and a side-effect would be that tool implementers would need to be more involved in the standards process and perhaps form a new technical group.

The proposal is already controversial. “Please don’t grant official status to the current crop of JavaScript tooling … many JavaScript developers, myself included, would like to rely less on these tools,” said one.

There is widespread agreement that prioritizing security, performance and stability is a good thing, but the notion of making JavaScript dependent on intermediate tooling is not popular. “RIP Vanilla JS” said another developer.