Microsoft, Igalia and Bloomberg They announced a few days ago that have taken the initiative to include a syntax for the explicit type definition in the specification JavaScript, similar to the syntax used in the TypeScript language.
Currently, the prototype changes proposed for inclusion in the ECMAScript standard have been submitted for preliminary discussions (Stage 0).
Today we are pleased to announce our support and collaboration on a new Stage 0 proposal to bring optional and erasable type syntax to JavaScript. Because this new syntax would not change the way the surrounding code is executed, they would effectively act like comments. We think this has the potential to make TypeScript easier and faster to use for development at all scales. We would like to talk about why we are pursuing this and how this proposal works at a high level.
It is mentioned that at tHaving explicit type information will prevent many errors in the development process, it will provide the opportunity to use additional optimization techniques, simplify debugging, and make the code more readable and easier for third-party developers to modify and maintain.
Besides that it is proposed to implement type support as an optional function: JavaScript engines and runtimes that do not support type checking will ignore annotations with type information and process the code as before, perceiving type data as comments. But type checking tools will be able, based on the information available, to detect errors related to incorrect use of types.
Background
A recent trend our team has seen in the JavaScript world is the demand for faster iteration time and reduced build steps. In other words, “make it faster and simpler”.In a way, this is already happening. Thanks to the success of evergreen browsers, developers can often avoid compiling newer versions of JavaScript to run on older runtimes. To some extent, the same goes for bundling: most browsers have built-in support for using modules, so bundling can be seen as more of an optimization step than a necessity. This has increasingly been the case, so how does TypeScript hold up?
At the same time, unlike the specified type information via JSDoc annotations specified as comments, the direct specification of types directly in variable definition constructs it will make the code more visual, understandable and easier to edit.
For example, TypeScript-enabled IDEs will be able to immediately highlight errors in written JavaScript code without additional transformations. Additionally, built-in type support will make it possible to run programs written in scripted JavaScript dialects like TypeScript and Flow without transpiling from one language to another.
Of the types, it is proposed to add "string", "number" and "boolean", which can be used when defining variables, function parameters, object elements, class fields, typed arrays ("number[]"). It is also proposed to provide support for mixed types ("string | number") and generics.
Given all of this, we plan to present this proposal for Stage 1 at the next March 2022 plenary meeting of TC39. We will do so with the support and guidance of our co-champions of this proposal, Rob Palmer at Bloomberg and Romulo Cintra at Igalia.
Reaching Stage 1 would mean that the standards committee believes compatible type syntax for ECMAScript is worth considering. This is not a sure thing: there are many valuable perspectives within the committee, and we expect a certain amount of skepticism. A proposal like this will receive a lot of comment and proper scrutiny. It can involve a lot of design changes along the way and it can take years to get results.
at the next meeting of March of the TC39 committee, it is planned to move to the first stage consideration of the proposal with the participation of the ECMA expert community.
Finally If you are interested in knowing more about it, you can check the details in the following link