The "Types as Comments" proposal for JavaScript, which aims to allow type annotations without requiring a build step, has been under discussion in TC39 for several years. While many developers are eager to see native type support in JavaScript, the proposal faces significant challenges that may delay its progress for a long time—or even prevent its adoption altogether.
The Proposal
The goal of "Types as Comments" is to give developers the ability to write type annotations directly in JavaScript while ensuring that they are completely ignored by JavaScript engines at runtime. This means that they do not introduce new runtime semantics and remain purely for tooling purposes.
The proposal aims to provide an ergonomic way to declare types without requiring transpilation, making type annotations more accessible without adding extra complexity to the language itself. If accepted, this would mean developers could write code like this and run it directly in a JavaScript engine:
function add(a: number, b: number): number {
return a + b;
}
The types would act as comments and be ignored by the JavaScript runtime, but they would still be available for type checkers like TypeScript and Flow.
Discussions
March 29, 2022 (Initial Presentation)
The proposal was first introduced by Daniel Rosenwasser from the TypeScript team and quickly gained strong support from the TypeScript community. However, concerns emerged regarding its scope and potential impact on JavaScript. One of the main objections was that the syntax was heavily influenced by TypeScript, raising questions about whether it would be truly neutral. Additionally, the proposal introduced a significant number of new grammar rules, which some committee members feared could fragment the language. As an alternative, suggestions were made to explore other ways to support TypeScript in JavaScript environments, such as enabling TypeScript parsing directly in developer tools instead of modifying the language itself.
March 31, 2022
The proposal advanced to Stage 1, but only after its scope was clarified. The committee agreed to explore a simpler syntax while ensuring that it remains neutral to existing type systems like TypeScript and Flow. Additionally, there was an ongoing debate about whether this could serve as a long-term step toward unifying JavaScript and TypeScript, or if it risked fragmenting the language even further.
March 22, 2023
Further discussions revealed significant ambiguities in the proposed syntax, making parsing more complex than initially expected. One example that caused issues was:
async as (x: y) => z;
In this case, it was unclear whether as was being used as a function name or as a type assertion, highlighting the difficulty in distinguishing between type annotations and regular JavaScript expressions.
To address these concerns, some members suggested introducing an explicit opt-in mechanism, such as:
"use types";
This directive would indicate that a file contains type annotations, helping to prevent conflicts with existing JavaScript syntax. However, this idea sparked further debate on whether such an opt-in approach would be necessary or if a more seamless integration could be achieved.
September 27, 2023
During this meeting, discussions shifted towards the broader implications of integrating type annotations directly into JavaScript. Some members questioned whether this proposal would truly simplify development or if it would introduce additional complexity. Concerns were raised about potential misunderstandings from developers who might assume the annotations would enforce runtime type checking, similar to statically typed languages. Additionally, the debate continued on whether JavaScript engines should allow some form of optional runtime type reflection in the future, though this was largely dismissed as being out of scope. There was also renewed discussion on whether an opt-in directive such as "use types"; could mitigate syntax ambiguities, but consensus remained elusive.
Current Status
The proposal remains in Stage 1 with no clear path forward. Grammar ambiguities persist, making it difficult to reach consensus on how type annotations should be structured. A major point of contention is whether JavaScript should adopt TypeScript’s syntax or develop a completely new annotation format that is more neutral. Additionally, discussions continue around the possibility of enforcing an explicit opt-in mechanism, such as a "use types" directive, to prevent unintended conflicts with existing JavaScript syntax. Despite ongoing debates, no concrete resolution has been reached, and opposition from some committee members remains strong.
So...
The proposal faces several challenges that could delay its adoption for a decade. These include syntax conflicts, as type annotations closely resemble regular JavaScript code, making them difficult to parse unambiguously. There are also standardization challenges, as TC39 must balance the needs of TypeScript, Flow, and other type-checking tools while ensuring backward compatibility to avoid breaking existing codebases. Performance considerations are another factor—while type annotations would be ignored at runtime, parsing overhead must remain minimal. Finally, opposition from some committee members remains strong, with some TC39 delegates arguing that the current approach is fundamentally flawed and could create confusion.
If you're expecting this to become part of JavaScript soon, you may need to be patient. Given the current state of discussions, it may take several more years before it becomes a reality.
Top comments (0)