5 ms·

stupid question: why doesnt google chrome support native typescript execution on their chromium engine?

Analemma_ 11mo ago
I'm not enough of an expert in PL theory and compilers to say for sure, but I suspect that because Typescript's syntax and semantics are all designed with total type erasure in mind, there's no advantage you could get to executing it natively versus compiling to JavaScript and taking advantage of all the optimizations JS engines already have.
benbayard 11mo ago
It's not a stupid question, but here is the TC39 proposal to add type declarations to JS: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
ZiiS 11mo ago
Different projects use different versions of typescript with different configurations, and almost no one wants the client to throw type errors where the untyped code would have actually worked. I.e. the are drawbacks but no advantages. This is ongoing standardisation work to allow it to _ignore_ typescript and just run the JavaScript which will be nice but not a huge win.
- klysm 11mo ago
  > no one wants the client to throw type errors where the untyped code would have actually worked That’s not how TypeScript works. You execute it after erasing the types.
  - antihero 11mo ago
    Unless you use enums, of course.
    - jauco 11mo ago
      Or constructor property initializers. constructor(public foo: string){} Is a typescript feature.
  - ZiiS 11mo ago
    Exactly so all the Browser should do is erase the types. Doing that after you have spent extra time downloading and parsing them is not a useful enough feature to lumber the language with having to get all Browser's to ship each new change.
paxys 11mo ago
"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptions for mismatches. This isn't going to be possible without a major rewrite of the v8 engine and the ECMAScript spec itself. And a big challenge for both of these is that TypeScript is iterating at too fast a pace for something like Chrome to keep up. It's best to just leave versioning and compilation for the developer to manage and give end users a consistent JavaScript experience.
- oskarkk 11mo ago
  I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully. I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type. For option 1 the speed of TS development is not an issue, as Chrome would only need to include some up-to-date compiler, and the TS files could specify their TS version. But doing TS compilation in the browser would only be a small nice thing for devs, for website users it would be a downgrade, as the page load would be slower because of the compiling and the larger file sizes (JS files can already be very big these days).
  - bastawhiz 11mo ago
    It's unclear whether you could build a JIT that meaningfully benefits from typescript types. 1. Hidden classes can't be created from TS interfaces because they don't represent the full data of the underlying object 2. You don't really ever want to compile code the first time you see it, because that takes a lot of memory and extra CPU cycles. By the time code has run enough to be worth compiling, you probably have enough profile data to optimize better than you could with data from the types anyway. 3. Many of the juiciest optimizations come from types that aren't representable in TS, like integers. 4. Including all the types for all your code and deps (literally all the .d.ts) is huge, and the size increase alone might nullify any performance benefit.
halapro 11mo ago
Because TypeScript is a (legacy) mess. There's effort towards "erasable syntax" but in practice not many really want to run anything more than basic TS in the browser, simply because you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects. The real reason however is that TS is just a language, not part of any standard, and browsers are not just going to support random languages headed by corporations (Microsoft) and that are not community projects.
- nikeee 11mo ago
  The "types as comments" proposal has a stated goal to not codify any semantics to the annotations. This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
  - conartist6 11mo ago
    That proposal is a practical joke. You haven't got a language at all if the words don't mean anything.
    - WorldMaker 11mo ago
      It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.
      - conartist6 11mo ago
        If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!

I'm not enough of an expert in PL theory and compilers to say for sure, but I suspect that because Typescript's syntax and semantics are all designed with total type erasure in mind, there's no advantage you could get to executing it natively versus compiling to JavaScript and taking advantage of all the optimizations JS engines already have.

benbayard 11mo ago

It's not a stupid question, but here is the TC39 proposal to add type declarations to JS: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

ZiiS 11mo ago

Different projects use different versions of typescript with different configurations, and almost no one wants the client to throw type errors where the untyped code would have actually worked. I.e. the are drawbacks but no advantages. This is ongoing standardisation work to allow it to _ignore_ typescript and just run the JavaScript which will be nice but not a huge win.

klysm 11mo ago
> no one wants the client to throw type errors where the untyped code would have actually worked That’s not how TypeScript works. You execute it after erasing the types.
- antihero 11mo ago
  Unless you use enums, of course.
  - jauco 11mo ago
    Or constructor property initializers. constructor(public foo: string){} Is a typescript feature.
- ZiiS 11mo ago
  Exactly so all the Browser should do is erase the types. Doing that after you have spent extra time downloading and parsing them is not a useful enough feature to lumber the language with having to get all Browser's to ship each new change.

paxys 11mo ago

"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptions for mismatches. This isn't going to be possible without a major rewrite of the v8 engine and the ECMAScript spec itself. And a big challenge for both of these is that TypeScript is iterating at too fast a pace for something like Chrome to keep up. It's best to just leave versioning and compilation for the developer to manage and give end users a consistent JavaScript experience.

oskarkk 11mo ago
I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully. I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type. For option 1 the speed of TS development is not an issue, as Chrome would only need to include some up-to-date compiler, and the TS files could specify their TS version. But doing TS compilation in the browser would only be a small nice thing for devs, for website users it would be a downgrade, as the page load would be slower because of the compiling and the larger file sizes (JS files can already be very big these days).
- bastawhiz 11mo ago
  It's unclear whether you could build a JIT that meaningfully benefits from typescript types. 1. Hidden classes can't be created from TS interfaces because they don't represent the full data of the underlying object 2. You don't really ever want to compile code the first time you see it, because that takes a lot of memory and extra CPU cycles. By the time code has run enough to be worth compiling, you probably have enough profile data to optimize better than you could with data from the types anyway. 3. Many of the juiciest optimizations come from types that aren't representable in TS, like integers. 4. Including all the types for all your code and deps (literally all the .d.ts) is huge, and the size increase alone might nullify any performance benefit.

halapro 11mo ago

Because TypeScript is a (legacy) mess. There's effort towards "erasable syntax" but in practice not many really want to run anything more than basic TS in the browser, simply because you lose things like 'import _ from "lodash", which requires further setup (import maps) or is impractical in larger projects. The real reason however is that TS is just a language, not part of any standard, and browsers are not just going to support random languages headed by corporations (Microsoft) and that are not community projects.

nikeee 11mo ago
The "types as comments" proposal has a stated goal to not codify any semantics to the annotations. This is not only due to implementation complexity, but also to keep TS to be able to change. Or even to build an entire different JS superset. With that proposal, even flow could be natively executed.
- conartist6 11mo ago
  That proposal is a practical joke. You haven't got a language at all if the words don't mean anything.
  - WorldMaker 11mo ago
    It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments. Comments don't mean anything to the parser/compiler either, but they mean a lot to the people writing the source files and they still need syntax to write them.
    - conartist6 11mo ago
      If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!