First in the front of the public number from the advanced to the hospital, welcome attention.

Hi, I’m SSH. The TypeScript team sent out a tweet in the middle of the night asking cryptically, “What if we could support types directly in JavaScript?” .

They say in the comments section that the “type as comment” proposal means that browsers can run code that passes the TS check (even if they don’t do any type checking). This means a better editing experience and faster iterations.

It’s a very exciting idea, so let’s look at what this proposal is all about.

This is a new stage0 syntax proposal that has not been submitted to TC39. The github repository is github.com/giltayar/pr…

background

One of the trends our team has seen recently in JavaScript is the need for faster iteration times and fewer build steps. In other words, “faster and easier”.

To some extent, this is already happening. Thanks to the success of browsers, developers can often avoid compiling newer versions of JavaScript to run on older runtime versions. To some extent, the same is true of builds — most browsers have built-in support for Modules, so builds become an optimization step rather than a necessary one. How does TypeScript follow suit in this case?

If we go back to 2012, when TypeScript was first released, the world of JavaScript would be very different! Some browsers update frequently, but others don’t. It’s unclear how long the older versions of Internet Explorer will last, which has led to the proliferation of tools like build tools and compilers. TypeScript can thrive in an era of adding build steps to JavaScript — after all, if you need to compile JavaScript, why not compile your types too? However, if the trends we mentioned above continue, compilation types may be the only step between writing TypeScript code and running it, and we don’t want to be the ones who get in the way of a good development experience!

In some ways, our JavaScript support fills this gap, and if you use an editor like Visual Studio or Visual Studio Code, you’ve probably seen JSDoc form adding type comments:

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

Because these are just comments, they don’t change the way your code works at all — they’re just a form of documentation, but TypeScript takes advantage of them to give you a better JavaScript editing experience through code completion, automatic refactoring, and so on. You can even add type checking by adding the // @ts check annotation at the top of files, or run these files with the checkJs option enabled through the TypeScript compiler. This feature allows you to get a portion of the TypeScript experience without a build step, and you can use it for small scripts, basic web pages, node.js server-side code, and more.

However, you’ll notice that this is a bit verbose and loses the brevity of TypeScript write types.

What if we want them all?

If we can have some syntax like TypeScript that is completely ignored in JavaScript — kind of like comments.

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

Our team believes there is a lot of potential here and we hope to submit it as a proposal to the ECMAScript Standards Committee TC39 this month!

How does it work?

When we were asked “When will JavaScript have types?” “We answered hesitantly. In the past, if you asked developers what they thought about types in JavaScript, you’d get a lot of different answers. Some people think that types should be ignored entirely, while others think that they should have some kind of meaning — perhaps they should perform some kind of runtime validation, or they should serve as hints for engine optimization, and so on. But in the last few years, we’ve seen a shift toward a design that’s in line with TypeScript’s direction, where types are completely ignored and erasable at runtime. Now we can confidently propose “type as annotation”.

The idea is that you can create a set of syntaxes that JavaScript completely ignores, but that TypeScript, Flow, etc., can use. This allows us to preserve what you love about TypeScript — its type-checking and editing experience — while eliminating the build steps required for development.

As a result, the toolchain looks a little different when you write and run code.

In the meantime, writing code and type checking will remain the same. Developers can get instant type-checking feedback in typescript-enabled editors, run TypeScript on the command line, and add TypeScript to CI tasks. The biggest difference is that because we don’t need a build step, we’re going to significantly lower the entry barrier for JavaScript developers to experience the power of genres and great tools.

To do this, JavaScript simply provides type annotations, optional modifiers (?) on variables and functions. Etc. Add syntax for parameters and class members, type declarations (interface and Type aliases), and type assertion operators (as and!). None of this affects how the surrounding code works.

Visibility modifiers (such as public, private, and protected) are also supported; However, enum, namespace takes parameter properties outside the scope of this proposal because they have visible runtime behavior. Based on feedback, these features could be proposed as separate ECMAScript features, but our current goal is to support some large subset of TypeScript, which we think could be a valuable addition to JavaScript.

With this breakthrough, we provide room for innovation in type checkers. This does mean that the engine will run the code smoothly, but we believe that type checkers can (and should) be prescriptive and enforce stricter constraints than runtime. Taken together, this creates a type syntax that can be customized across different checkers, or removed if someone decides they’re not happy with TypeScript or any other type checker.

What isn’t this?

It is worth noting that this proposal is not.

Our team is not proposing to put TypeScript type checkers in every browser and JavaScript runtime — nor are we proposing any new type checkers to put in browsers. We believe this can lead to a number of problems for JavaScript and TypeScript users, such as runtime performance, compatibility issues, and stifling innovation in the type space.

Instead, we’ve just come up with typescript-compatible and driven syntax that can be used by any type checker but skipped by JavaScript engines. We believe this approach is the most promising for everyone and will continue to allow TypeScript, Flow and others to continue to innovate.

The next?

In view of all this, we plan to present Stage 1 proposals at the upcoming TC39 plenary in March 2022. We will do this with the support and guidance of our co-sponsors, Rob Palmer of Bloomberg and Romulo Cintra of Igalia.

Reaching stage 1 means that the standards committee thinks supporting type syntax is worth considering for ECMAScript. This is not something that is sure to cause a stir – there are many worthy points of view within the committee and we do expect some scepticism. Such proposals get plenty of feedback and proper scrutiny. This process can involve extensive design changes and can take years to produce results.

But if we get it all done, we have a chance to make one of the most impactful improvements to the JavaScript world. We’re excited about it, and we hope you are too.

If you are interested in more details and information on current directions, please head over to the proposal’s repository. We look forward to hearing your thoughts!

Finally, the TypeScript team and Champions Group would like to thank everyone who works on existing technology, as well as the contributors who have helped with the review, especially Gil Tayar, who helped drive this work. We are so grateful to be part of such a passionate community!

First in the front of the public number from the advanced to the hospital, more interesting front-end articles, welcome to pay attention to.