Will native JS also support type annotations in the future?

Hello everyone, I'm Casson.

At JSConf 2022 in Budapest , Gil Tayar , member of tc39 (ES Standards Committee), introduced a proposal that is still in the stage 1 stage Type Annotations , which is intended to allow native JS supports type annotations.

In other words, if the proposal passes, many .ts files will be able to run directly in the browser after the suffix is changed to .js .

A tc39 proposal usually goes through 5 stages:

• stage 0: proposed
• stage 1: Under review
• stage 2: The specification is basically completed
• stage 3: waiting to be implemented
• stage 4: Incorporation into language standards

So Type Annotations is still under review .

However, the sponsor of the proposal, Gil Tayar , is very confident in the passage of this proposal. In this article, we will talk about the relevant content of this proposal.

Welcome to join the human high-quality front-end framework group , with flying

Why do you need native type annotations?

According to the statistics of state of JS in 20 and 21 years, static type was voted as the most lacking function in JS .

Meanwhile, in the Github report , TS is listed as the fourth most used language

Therefore, for front-end engineers, type annotations are in great demand.

So, since we already have TS , why do we need native JS to support type annotations ?

Generally speaking, code compilation is required between the source code written by the developer and the code in the online production environment .

Code compilation mainly includes two steps:

1. Downgrade compilation (including conversion of high-level syntax to low-level syntax, high-level method polyfill )
2. Code translation (e.g. compression, obfuscation, tree-shaking, type erasure)

The so-called type erasure refers to erasing the type annotations in the code to make it conform to the native JS specification code, such as:

 // 擦除前
function add(a: number, b: number): number {
  return a + b;
}
// 擦除后
function add(a, b) {
  return a + b;
}

Over time, as the major browsers become more compatible, step 1 will gradually decrease in importance for the foreseeable future.

For TS developers, only type erasure may be required between source code and live production code .

If the native JS supports type annotations , the compilation process corresponding to type erasure can be omitted, making the code easier to execute in the host environment.

Relationship with TS

The purpose of this proposal is not to start anew and independently implement a set of native JS type annotations. Instead, work with the TS team to come up with an appropriate set of specifications.

The relationship between the new specification and the TS specification is similar to the following figure:

On the one hand, the Type Annotations proposal borrows a lot of features from TS , and this is the part where the graph intersects.

You can go to grammar-conventions to see the types currently defined by the specification

On the other hand, TS iterates very quickly, and new features are produced quickly. And Type Annotations as part of JS language, the iteration will be more conservative, so some features in TS Type Annotations are not supported in ---fbcdea4940e5e476b.

Additionally, some constructs in TS (eg Enums , Namespaces ) do not have runtime semantics, Type Annotations

These are the TS that exist in Type Annotations and do not exist in ---c0f6c01768377eb0dac200a6377a27b8---.

Finally, Type Annotations is not designed to be strongly bound to TS , but only to provide a set of type specifications. The type check when developers write code is still performed by various type checkers (eg TS , Flow ) to implement.

Therefore, Type Annotations there are some features that are TS not currently defined, which is also considered for the wider applicability of the specification, that is, the figure Type Annotations exists , while the TS part does not exist.

This part of the feature needs TS to be implemented later, which is one of the reasons why Type Annotations and TS teamwork.

What it means for developers

If Type Annotations finally appears in the ES20xx version, then the steps for developers to write code are:

1. Choose an appropriate type checker (eg TS ), which needs to fully follow the Type Annotations specification (and not its own, eg TS specification)
2. Write native JS code with type declaration
3. The type checker will check for type errors and give errors or hints

For the following native JS code, if the developer passes in the wrong type, JS will report an error?

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

// 错误的类型传参
add('KaSong', 123);

The answer is: no.

Type Annotations is just a set of specifications, which are enforced by various type checkers.

JS host environment (such as browser) will ignore the type declaration when executing JS code with type declaration.

Summarize

Some students may ask: Is it necessary to propose a native type specification in order to reduce the step of type erasure at compile time?

Even when Type Annotations is implemented, when developers compress code before going online, type erasure will be one of the responsibilities of code compression .

From this point of view, it doesn't even reduce the work at compile time.

So, is it necessary to propose a native type specification?

Front-end development is actually a process of trying to compile-time flow .

For example, the code needs to be downgraded at compile time, need polyfill ? As IE11 stopped serving, the mainstream browsers followed the implementation of the standard, and the demand for downgrade and polyfill gradually decreased.

Another example, the code needs to be packaged? With the implementation of the ESM specification, at least in the development environment, the code no longer needs to be packaged (using Vite ).

The emergence of Type Annotations is a product of following the trend of trying to compile-time flow .

From this point of view, it is still necessary.