Chakracore: Add native support for TypeScript.

[ninlar]

I know this would require a massive amount of work in ChakraCore, but a man can dream right?

It would be great if ChakraCore could run scripts written in TypeScript without having to first transpile it to JavaScript. This would have an additional benefit: it could perform better. I imagine the JIT compiler could potentially produce better optimized native code, if the user doesn't litter their TypeScript with the "any" type. Even if the TypeScript used "union" types, the additional type information could produce better optimized machine code without having to first interpret the code and collect type information during early runs.

[dilijev]

This is something we have talked about within the team. As you say, it would be a massive amount of work. If we believed that amount of work would have a correspondingly great benefit for our customers, we would absolutely target this goal. Here's a few reasons we have decided not to, for now:

• We are committed to web standards, and TypeScript is not a web-standard language at the moment, nor is it planned to be. Which is to say, if we allowed a web page to run TypeScript, Edge might be the only browser to ever support it, which means websites would not be likely to use that feature (or would still have to code websites to fall back on JS if TypeScript isn't supported).
• In terms of highly-performant web languages we already have much better options, which we do invest in because they are web standards with huge benefits for their class: asm.js and Web Assembly.
• For the majority of scripts on websites, lack of specific type information is not really a significant bottleneck. We already do a very good job of optimizing for common patterns even without knowing the types ahead of time.
• TypeScript is designed to be compiled to JavaScript, with the compiler doing the type checks. We would essentially have to do similar checks at runtime to make sure the code wasn't written in a way which violates the type annotations. Doing so would increase the runtime in favor of enforcing the semantics. And, what do we do if the type semantics are violated? Fall back to JS (which would require at a minimum a re-JIT among other things)? Stop execution of the TypeScript code altogether? The existing approach already allows us to tolerate unexpected types and re-JIT accordingly. (Maybe we could design a solution to these problems. In any case, we would have to have a reasonable candidate implementation before we could do the perf comparison in anything beyond a theoretical sense.)

If there comes a time that Edge and Windows do not account for the massive majority of the JS code that our engine runs as they do today, and things are shifting in favor of scenarios where one could run native TypeScript, maybe we would see a bigger benefit, but for now, we feel there are much better ways to invest our resources to make improvements in the web and NodeChakra scenarios, all without disrupting the status quo for JS developers.

[gulshan]

I think it's a good thing that Chakra is not trying to run Typescript code directly. But if Typescript definition files or .d.ts files are available to Chakra alongside JavaScript files, can that be somehow used to improve performance or something like that?

[Cellule]

The problem with Typescript is even though it tries to enforce types, your script can load code from libraries which .d.ts could be wrong or outdated.
Also, you are allowed to use the any type and casts which can then leak variables of unknown types into your typed code.
This means we can't use the types as-is, we would have to make sure the types are enforced at run-time.

Currently we retrieve the type information of variable while running in the interpreter gathering profile data.
This profile data is then used to guess the type of your variables.
At most, Typescript type information would allow us to minimize the amount of time spent in the interpreter and directly use the types as profile data.
I don't think we could generate much better code, just generate it sooner.

On the other hand, using Typescript today enforces good practices in regards to types for your code which makes our job easier to then infer the types when gathering profile data
It also has fewer chances of changing types in future calls, thus invalidating our assumptions.

[DemiMarie]

@Cellule is the basic problem that type-based optimizations generally require that the type system be sound, which TypeScript isn't, and runtime checks where typed and untyped code meet, which would be difficult?

[bterlson]

@DemiMarie that is one of the basic problems, yes. Google actually went down the path of creating a sound type system for a JS subset and found it extremely difficult or impossible to do well. You can read more here: https://groups.google.com/forum/embed/?place=forum/strengthen-js#!topic/strengthen-js/ojj3TDxbHpQ.

[dilijev]

Closing as Question Answered / Won't Fix

[dilijev]

Adding the question tag so this Discussion can be found by people wondering "Why doesn't Chakra run TypeScript directly?"

[XadillaX]

https://github.com/ry/deno

[bradenhs]

Even if TypeScript was just supported by the parser it would be great for development. The parser could accept typescript syntax but strip out all typescript specific things and run the code as it typically would normal javascript. People typically run a typescript type checker in a different process while in development anyhow to get a faster feedback loop. If Chakra were to do this I imagine a lot of TS devs would make Edge their development browser instead of Chrome since the feedback loop while in development mode would be faster.

[Cellule]

@bradenhs That would mean to have the whole typescript compiler embedded in Chakra to transpile the code. Unfortunately, Typescript is not just type annotation that we can strip out. Additionally, how would we know which version of Typescript to use.

The likely scenario is that a lot of dev would have to keep using Typescript themselves because of version mismatch between their normal workflow and the version used by Chakra. Not to mention the difference in deployment interval between Chakra and Typescript.

[bradenhs]

Yeah there would be some major complications depending on how you decided to do it. I would imagine Chakra would just extend it's current parser to support the latest ts syntax as opposed to embedding typescript inside of it. There may be some issues there since there would be more than one source of truth for how the parsing was done. The whole process however would be simplified by the fact that an extended chakra parser wouldn't need to do anything with the typescript specific tokens other than just ignore them. Typically later versions of typescript don't invalidate syntax of previous versions so I don't imagine a ton of churn but idk. It'd be hard but not as hard as doing actual typechecking functionality as well. I'm pretty unfamiliar with the source code of either project so I realize I'm missing a ton but thought I throw the idea out there :)

[bradenhs]

I'm sure most people have seen this but thought I'd mention it: https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/. Looks like the latest babel has a configuration that accepts typescript specific syntax but just throws it away. It would be great if Chakra could do this as well. Admittedly they're much different tools I but thought I'd share. With es6 modules being supported by browsers natively the opportunity to eliminate the time taken by the both a bundler and the ts compiler would be great for development.