Comment by paxys

Comment by paxys 19 hours ago

4 replies

"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 15 hours 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 9 hours 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.

  • mdhb 6 hours ago

    If you want proper run time type safety you’re going to need a language designed for that which Typescript never was. I write a bunch of Dart which I compile to Wasm and get proper run time type safety in the browser and it works great.

eternityforest 11 hours ago

1. Would still be meaningful, since it would pretty much mean we could completely ignore untyped JS code aside from legacy support, the same way we can currently pretend untyped python doesn't exist