Why Moddable supports JS0/JSSugar

November 13, 2024

Why Moddable supports JS0/JSSugar

Proposed changes to how the JavaScript language evolves have generated a lot of discussion recently. The proposal, titled "Language Evolution: Problems, and What Can We Do About It?" was delivered by Shu-yu Guo of Google and supported by Apple, Moddable, Mozilla, and Sony. "Language Evolution" explains that JavaScript engine developers are increasingly struggling with the competing goals of supporting the latest language features and protecting users running JavaScript especially in the browser. While the creators of every JavaScript engine have long made large investments to support developers, ultimately the privacy, security, and safety of users must take priority given the many critical ways JavaScript is used today. The proposal lays out a path forward that balances these competing priorities.

Implementing JavaScript isn't Easy

Implementing a JavaScript engine is tough. That is easy to overlook because JavaScript works so well these days. That's thanks to careful work by the language committee, editorial improvements to the standard document, investments in the test262 conformance test suite, increasingly sophisticated fuzzers, and much more. Still, the language specification is now over 800 pages of dense, highly technical, intertwined text. Implementing that correctly delivers a conformant JavaScript engine, but not a useful one.

Optimizations are what make a JavaScript engine useful in a particular field. But optimizations are also what make implementing a JavaScript tough. For example, the JavaScript engines in web browsers are optimized to be incredibly fast. That adds significant complexity which, unsurprising, results in the majority of security vulnerabilities. Moddable's XS JavaScript engine for embedded systems is optimized to minimize resource requirements, such as memory and the size of the engine code. Unsurprisingly, most security vulnerabilities in XS have been related to these optimizations.

We can't live without optimizations. They are what make the engines for the web so great. They are what XS unique. But each new language feature potentially interacts with those optimizations in new and sometimes unanticipated ways. To ensure the safety of users, engine implementors need to slow the pace of these changes to have the time to get new features right.

Building on Build Tools

The solution offered by the "Language Evolution" proposal is to divide JavaScript into two parts. The first part is the core language, called "JS0", that is implemented by JavaScript engines. The second part is standard language features, known as "JSSugar", that are implemented by transpilation tools that compile them to JS0. JS0 will evolve relatively slowly to better protect users. JSSugar, by contrast, should evolve more quickly since there are fewer concerns to consider.

A key insight of the proposal is that JavaScript developers today are already using tools to transform their JavaScript for use in web browsers and server environments such as Node.js. These tools include TypeScript, Babel, and a variety of packagers and minimizers. The tooling ecosystem for JavaScript is so strong that these transpilations are nearly invisible to most developers, even when debugging their JavaScript.

Because so many developers are already transpiling their JavaScript, it makes sense to use that step to both simplify and secure how JavaScript evolves.

Impact on Embedded Developers

The "Language Evolution" proposal has many advantages for embedded developers using our XS JavaScript engine. One of the biggest concerns we've heard is about the impact on the development process, so let's start there.

Building

Embedded developers using the XS through the Moddable SDK may not realize it, but their JavaScript source code is already transformed by build tools before being downloaded to a microcontroller. The build system in the Moddable SDK automatically invokes both xsc, the XS compiler, and xsl, the XS linker. The compiler converts JavaScript source code to XS bytecode and the linker merges the bytecode files before optionally running the project initialization code in a special preload phase. For embedded developers working in TypeScript, the Moddable SDK build system automatically invokes tsc, the TypeScript compiler, to transpile TypeScript to JavaScript.

All of this happens in the blink of an eye. Developers don't have to do any special build configuration. When JSSugar becomes available, we'll update our build system to automatically invoke it as well. Embedded developers using the Moddable SDK will continue to work exactly as they do today.

Debugging

Because JSSugar transforms source code into JS0, developers might expect to see transpiled JS0 code when debugging. That could be confusing. Fortunately, developers will continue to see their original source code when debugging. That's thanks to "source maps" which provide a map from the transpiled code back to the original source code. The Moddable SDK already supports source maps so TypeScript developers can debug their TypeScript source code directly.

Source maps have long been part of the JavaScript ecosystem as an ad-hoc standard supported somewhat inconsistently by tool providers. Recently the JavaScript language committee launched TG4 to standardize source maps. This will improve interoperability across the entire JavaScript ecosystem, which is essential for JSSugar.

Access to New Language Capabilities

Language features which are defined entirely in JSSugar should be available simultaneously to developers working in every environment – web browsers, web servers, and embedded. For the many developers working across multiple environments, the proposal makes JavaScript more consistent because features will arrive at the same time across all of them.

This will help our embedded developers keep up to date while reducing the effort the XS engineering team needs to make to support these new features.

Security and Stability

The benefit of a more secure and stable JavaScript language is the most difficult to quantify but also the most critical. IoT products are part of our everyday world, controlling pumps, motors, heaters, locks, lights, and more. Our well-being depends on them. We need to trust that they operate reliably every minute of every day and that they protect us from attacks by bad actors. Embedded JavaScript is a key part of IoT device reliability and security.

Moddable invests substantial time and energy diligently ensuring the security and stability of XS. It is a significant undertaking, and we have been fortunate to have strong support from Agoric in this effort. It starts with careful engineering design, implementation, and conformance testing. But that's not enough. We are continuously testing XS with the Fuzzilli and AFL fuzzers to search for obscure errors that could become security vulnerabilities. We also publish detailed information about XS to aid independent security researchers searching for vulnerabilities.

In the world envisioned by this proposal, our efforts to harden XS can focus on JS0, which will save time by eliminating the need to test features in JSSugar. Because JS0 should evolve more slowly and more thoughtfully, the introduction of new vulnerabilities should also be slowed.

Engine Footprint

Unlike web developers, embedded JavaScript developers must consider the size of the JavaScript engine's code. Embedded devices can have as little as 1 MB of total storage space, which must hold the RTOS, JavaScript engine, and the developer's project. This constraint makes it essential that the JavaScript engine's code be as small as possible. Moddable has gone so far as to implement automatic dead-stripping of language features unused by a project to minimize the engine footprint.

The separation of many new language features into JSSugar means those features will not cause any growth in the engine code. The more measured pace of development of JS0 should slow growth of the engine and make additional size optimizations more feasible.

Looking Ahead

The "Language Evolution" proposal is just that: a proposal. The problems it addresses are very real. The solution it outlines may not be what the committee decides to standardize. But the benefits it offers are compelling and the path to deploying it – by extending existing tool flows – aligns well with how JavaScript developers work today.

Over 20 years after its creation, JavaScript remains one of the most important programming languages, used by millions of developers to create software used by billions of individuals. The way the language grows needs to evolve thoughtfully to meet the needs of both users and developers. Moddable remains committed to using our voice in the JavaScript language committee to advocate for proposals that improve the language for embedded developers and the users of the products they create. We support the “Language Evolution” proposal for JS0/JSSugar.