> As TypeScript is a core part of the Deno ecosystem, we are also very interested in pushing for even closer alignment of TypeScript and JavaScript in the future.

I've wondered why the frontend community hasn't gotten together and said, "The next version of JavaScript - is TypeScript!" I've been using TypeScript for five years professionally now and cannot understate how much easier it has made large frontend (not just Web, but mobile and desktop) projects. Surely enough thought and work has been put into TypeScript to make it the next standard.

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops.

There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static checking doesn't benefit end users. When I go to my bank's website, if their front-end code has a type error, it's not like I can fix it right then and there.

The type system is mostly a developer-time feature, so it makes sense to leave it out of the core runtime environment.

In other words, think of JavaScript/ECMAScript more like the architecture that browsers support. That needs to be slow-moving since it's deployed across billions of devices. TypeScript then just targets that.

Adding TypeScript directly to JavaScript would improve the world to about the same degree that adding C++ features directly to x64 machine code would.

This is not true. There are a number of ways that TypeScript's type-checking can be subverted at runtime, particularly when dealing with APIs that return JSON. You have to trust that the API has returned exactly what you are expecting, or write your own very detailed validation scripts. It's similar to the sorts of testing one would do in vanilla JavaScript without TypeScript, but now executing all the time at runtime.

As a developer, in the case of an API change that violated my assumptions, I would personally prefer my applications to fail-hard at the point of the API call, rather than to have my scripts run merrily on and only error in some other code far away from the root-cause when one of those assumptions fails.

However, I have a lot of hope that runtime type checking based on auto-code generation around TypeScript's interfaces could be developed in a future version of TypeScript.

Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard).

[1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zod