Microsoft proposes bringing TypeScript-like type syntax to JavaScript

; Date: Wed Mar 09 2022

Tags: JavaScript »»»» TypeScript

It's not every day you see TypeScript as a trending topic on Twitter. But, a proposal by Microsoft to bring type syntax to JavaScript is certainly a big deal worthy of being a Twitter trending topic. Types coming to JavaScript?

Those of you who like JavaScript as a non-typed language, don't worry. Microsoft's proposal is not to add type checking or enforcement to JavaScript. Instead, the proposal adds the syntax for type declarations, but to treat it as comments. Presumably that means a JavaScript engine could optionally pay attention to the type syntax and do something useful. But, the goal for now is to add more information to JavaScript code so that programming tools can do more useful things.

TypeScript (and Python) as trending topics next to Ukraine War news on Twitter

There is some awfully important stuff going on in the world. Theoretically the "trending topics" block on Twitter should reflect what's important. But, as I said above, it's not every day that something like TypeScript reaches this level of significance, so let's try to digest what this is about.

First, of course JavaScript has for its entire existence had minimally nonexistent support for types. It was possible to use typeof or instanceof to distinguish between things, and there were slight behavior differences between number and string, but generally speaking we've had a free-for-all in JavaScript. This is presented as a productivity enhancement, because JavaScript programmers have less to deal with while writing code. That's in contrast to Java programmers who have to dot every 'i' and cross every 't' to do anything.

As our JavaScript programs become ever larger it, in theory, becomes important for our code to be written with rigor. As I wrote in my book ( Quick Start to using Typescript and TypeORM on Node.js for CLI and web applications:

In a small application a single programmer can easily review the code to find coding mistakes, and keep the whole program in mind. But, in a huge application, developed by a large team, manually finding coding mistakes is much harder. It's likely that, in large applications, no one programmer can understand everything, making it harder to catch bugs with a visual code review.

While the book is about how to use TypeScript on Node.js, I felt it necessary to make the case for using types in JavaScript. Namely, we're writing bigger and bigger applications in JavaScript. I believe that means we need stronger tools in the JavaScript ecosystem to manage larger piles of code.

But.. I'm off on a tangent, because Microsoft's proposal is not about bringing type checking to JavaScript. Instead, Microsoft's proposal is solely about making it possible to use type syntax in regular JavaScript, and for the type syntax to be treated as a comment.

But - why bring the syntax to JavaScript only to ignore it? Obviously the purpose is for JavaScript tools to do something with the type information. That might mean tools like ESLint, or an IDE, or anything, could have richer information. With richer information, the tool could do ever-more-useful things for programmers.

Syntax examples for JavaScript+Types

It is proposed that the result be called JS+Types or JavaScript+Types.

( Microsoft's proposal notes that currently we can use JSDoc syntax like this:

 * @param a {number}
 * @param b {number}
function add(a, b) {
    return a + b;

JavaScript tools, like JSDoc, can look at these structured comments and do useful things. TypeScript, for example, can read those comments to give it information from which to perform type checking. JavaScript execution engines will ignore this, but other tools can pay attention to this to perform useful functions.

The proposal is for us to write this instead:

function add(a: number, b: number) {
    return a + b;

This is precisely the TypeScript syntax.

The ( Stage 0 proposal describes a number of specific syntaxes to support:

function stringsStringStrings(p1: string, p2?: string,
                            p3?: string, p4 = "test"): string {
    // TODO

let x: string;

interface Person {
    name: string;
    age: number;

type CoolBool = boolean;

class Person {
    name: string;
    constructor(name: string) { = name;

    getGreeting(): string {
        return `Hello, my name is ${}`;

const point = JSON.parse(serializedPoint) as ({ x: number, y: number });

type Foo<T> = T[]

interface Bar<T> {
    x: T;

function foo<T>(x: T) {
    return x;

class Box<T> {
    value: T;
    constructor(value: T) {
        this.value = value;

add<number>(4, 5)
new Point<bigint>(4n, 5n)

In other words, this is all straight out of TypeScript.

The proposed advantage of JavaScript+Types

With TypeScript, or Flow, there is a compilation step before code is executed. Programmers in lots of languages have compilation steps, but JavaScript programmers have never had that. It is a productivity boost to not require compilation before execution.

The proposal describes the type information as type annotations. As annotations, the type information in a declaration like const x: number = 42 is treated as a comment. This means most tools will parse the type annotation then ignore it. But other tools can be developed which additionally do something useful.

What's next?

Microsoft plans to propose this as a Stage 1 proposal at the March 2022 plenary meeting of the TC39 committee. At that stage, the ECMAScript committee would be believing that the feature is worthy of consideration for further development.

Would there be an option for a JavaScript execution engine to add type checking? No. Here's what Microsoft has to say:

We think doing that would cause problems for JavaScript and TypeScript users alike due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of halting innovation in the type-checking space.

Instead, we’re just proposing syntax that is compatible with and motivated by TypeScript, which could be used by any type-checker, but which would skipped over by JavaScript engines. We believe that this approach is the most promising for everyone, and would continue to allow TypeScript, Flow, and others to continue to innovate.

I believe this is an exciting step forward for the JavaScript ecosystem. It fits the model that TypeScript is used as a fertile ground upon which to experiment with language features, some of which will turn into official JavaScript language proposals. It will be interesting to see what programming tools become available once this feature is standardized.

About the Author(s)

( David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.

Books by David Herron