Eemeli Aro: JavaScript Needs Breaking Changes

JavaScript has fundamentally evolved from its origins, a testament to its longevity in internet years. Aro, having written websites before CSS existed, recalls the early days when JavaScript first emerged, highlighting its continuous development.

The language possesses a certain "vintage" quality, mirroring Aro's own experience with its long history. Despite its age, JavaScript has consistently functioned as the same core technology, which has allowed all content created in it over decades to remain operational.

While JavaScript's backward compatibility ensures old code continues to work across various environments, it also imposes a significant burden on the language's evolution. Aro's desired single change would be to establish a method for introducing breaking changes, making developers more comfortable with necessary updates.

Eliminating this restriction would be intriguing, though it might fundamentally alter JavaScript's identity.

Removing the "don't break the web" restriction could fundamentally change JavaScript, potentially transforming it into something unrecognizable. Aro admits uncertainty about the consequences, suggesting it might not be a wise path despite its theoretical appeal.

Many developers writing JavaScript today are, in fact, writing TypeScript. Although the JavaScript they produce can run directly in browsers or other environments, it's often not the case, particularly for web content.

This contrasts with browser environments, where optimizing performance for over-the-wire delivery and diverse client hardware is critical.

The direct execution of written code in server-side contexts has lower associated costs. However, for web browsers, which handle front-end execution, optimizing for transmission over the wire and diverse client hardware requires a different understanding of performance costs. This necessitates careful consideration for any language changes.

This approach faces a major hurdle: parsing TypeScript is more resource-intensive than parsing standard JavaScript.

If browsers were to directly support TypeScript, they would need to perform additional work.

Direct TypeScript integration would force browsers to do more work to identify and parse JavaScript, even if they ignore type content. Browsers would still need to detect and bypass type-related elements, which adds a processing overhead.

Instead, proposals focus on a subset of TypeScript, which would still require developers to use a processor.

Even with a subset of TypeScript, code would still need to pass through a processor to ensure compatibility across environments. If a tool is still required, Aro questions why developers wouldn't simply remove types during this processing stage.

Aro suggests that by removing types at the build stage, the performance cost of type parsing and processing can be handled during development, preventing client-side impact. He expresses skepticism about the value proposition of directly incorporating TypeScript into JavaScript at a fundamental level.

While direct TypeScript integration may not be ideal, other approaches could be considered. Theoretically, a new type hinting system distinct from existing TypeScript and Flow types could be designed for JavaScript.

This could introduce typing into JavaScript with minimal overhead, but it would not be TypeScript itself.

While a new type system could offer low or negligible parsing costs, it would not be TypeScript. Given that many developers already use TypeScript and rely on build tools, Aro questions the rationale behind making fundamental changes to JavaScript that could introduce costs without significant benefits over existing solutions.

Such changes would incur costs in various use cases without necessarily offering substantial benefits beyond what current systems provide.