In fact, this is a typical headline party, please feel free to spit on me. Browsers support running Typescript directly, which is something that hasn’t been done yet. It’s just the beginning, but forgive me for my excitement at the news. Full free translation, if misleading, please give up reading. A Proposal For Type Syntax in JavaScript

TL; DR

  • The main idea of this proposal is to selectively add a subset of the Typescript type system to the JavaScript syntax, but at the same time the JavaScript runtime can ignore and erase the type syntax.
  • What this proposal does not advocate is that you should not add type checking to javascript at runtime, because if you do, it can cause all sorts of problems. Examples include runtime performance issues, compatibility issues with existing TypeScript code, and barriers to innovation in the area of type checking.

Today, we are pleased to announce that we support and are working with third parties to advance the new Stage 0 proposal to bring optional and erasable type syntax to JavaScript. Because this new syntax doesn’t change how the surrounding code works, it effectively acts as a comment. We think this has the potential to make TypeScript easier and faster to use for development of all sizes. We want to talk about why we want to add types to JavaScript and how this proposal works at a high level.

background

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

In some ways, this is already happening. Thanks to The Evergreen Browser (what is Evergreen browser?) (mainstream browsers quickly implemented newer features of ECMAScript), and developers didn’t have to compile newer versions of JavaScript as much to be compatible with older runtimes. To some extent, the same is true of the packaging process — most browsers have built-in support for using the ES module, so the packaging process has come to be seen as an optimization rather than a necessity. As this happens more and more, TypeScript needs to figure out how to keep up.

If we go back to 2012 when TypeScript was first released, the JavaScript world is a very different place than it is today! At the time, only a few browsers iterated quickly and released frequently, while others did not. At the time, it wasn’t clear how long we would be stuck with older versions of Internet Explorer, which led to the widespread popularity of tools like packers and compilers. The era of adding build steps to JavaScript, and that’s where TypeScript really thrived-after all, if you need to compile your JavaScript, why not compile your types as well? However, if the trends we mentioned above continue (many of the new ECMAScript features run directly in browsers), compiling your type may be the only thing you need to do between writing TypeScript and running it. In fact, we don’t want to be the only obstacle to a good development experience!

In some ways, our JavaScript support fills the gap here, and if you use an editor like Visual Studio or Visual Studio Code, you might already see this. Today, you can create a.js file in the editor and start adding types in the form of JSDoc 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 how your code works at all — they’re self-documenting, but TypeScript uses them to provide you with “auto-supplement,” “refactoring,” and other better JavaScript editing experiences. You can even add type checking by adding the // @ts-check comment at the top of files, or run them from the TypeScript compiler with checkJs turned on. This feature makes it very easy to get some TypeScript experience without the build step. You can use it for small scripts, simple web pages, server code in Node.js, and so on.

However, you’ll notice that this is a bit verbose — we love the simplicity of writing JavaScript, but we miss the convenience TypeScript provides for writing types.

Kids make choices, adults make both. So what if we could have both? What if we could have TypeScript syntax in javascript, but at the same time it could be ignored like JS 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 formally address it in a proposal to the ECMAScript Standards Committee TC39 this month!

How will this work?

When we used to be asked “When does a type appear in JavaScript?” “We all hesitated, not knowing how to answer. Historically, if you took this question and asked developers what they thought about adding types to 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 — maybe they should enforce some kind of runtime validation, or they should be introspective, or they should serve as hints for engine optimization, and so on. But in the past few years, we’ve seen more of a shift toward design in the direction TypeScript is heading — a syntax where types are completely ignored and erasable at runtime. This convergence and the widespread use of TypeScript made us feel more confident when several JavaScript and TypeScript developers outside of our core team came back with a proposal called “Type as annotation.”

The idea is that JavaScript can create a set of syntax for types that the engine completely ignores, but that TypeScript, Flow, and other tools can use. This allows us to preserve what you love about TypeScript — its type-checking and editing experience — while eliminating the need for a build step in development.

As a result, the developer’s workflow will look a little different when writing and running 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 as part of their CI tasks. The big difference is that, because we don’t need a build step, we will significantly lower the bar for JavaScript developers to experience the type of experience and a powerful tool chain.

To do this, JavaScript needs at least optional modifiers (?) for variable and function type comments, parameters, and class members. , type declarations (interfaces and type aliases), and type assertion operators (as and!) All of this doesn’t affect how the surrounding code works.

Things like visibility modifiers (such as public, private, and protected) may also be in scope; However, enumerations (Enums), namespaces, and parameter properties would be beyond the scope of this proposal because they have observable runtime behavior. These features can be proposed as separate ECMAScript features based on feedback, but our current goal is to support some large subsets of TypeScript that we think might be valuable additions to JavaScript.

With this division, we make room for the type checker to innovate with the new syntax it needs. This does mean that the engine will happily run code with nonsense types, but we believe that type checkers can (and should) be prescriptive and enforce stricter constraints than at runtime. Taken together, this allows type syntax to be customized between different checkers, or if someone decides they’re not happy with TypeScript or any other type checker, they can write no type code in javascript at all.

We have nothing to advocate

We think it’s worth emphasizing what’s not being advocated in this proposal.

Our team does not recommend adding TypeScript type checking to every browser and JavaScript runtime — nor do we recommend adding any new type checking to the browser. We believe this creates the same problems for JavaScript users as it does for TypeScript users, due to a number of issues: runtime performance issues, compatibility issues with existing TypeScript code, and obstacles to innovation in the area of type checking.

Instead, we’ve just proposed adding typescript-compatible and inspired syntax to JavaScript that can be used by any type checker but ignored/skipped by the JavaScript engine. We believe this approach is the most promising for everyone and will continue to let TypeScript, Flow, and others continue to innovate with type systems.

What will we do next?

With all this in mind, we will be working with our co-sponsors, with the support and guidance of Rob Palmer of Bloomberg and Romulo Cintra of Igalia, Phase 1 proposals are planned to be presented at the upcoming TC39 plenary meeting in March 2022.

Reaching phase 1 means that the standards committee thinks adding type syntax to ECMAScript is a worthwhile idea. This is certainly not a done deal — there are many valuable points of view on the TC39 committee, and we do expect to be met with some scepticism. Proposals like this receive a lot of feedback and proper scrutiny. This process can involve extensive design changes and can take years to produce results.

But if we do all this, 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 learning more about specifics and current directions, please head over to the Proposal Library. We look forward to hearing from you and seeing your thoughts!

Finally, the TypeScript team and the proponents of the proposal would like to thank everyone involved in Prior Art and the contributors who lent a helping hand to the idea by participating in the discussion, especially Gil Tayar who helped spread the word about the idea. We are thrilled to be part of such a passionate community!