undefined | Better HN

0 pointsoskarkk3mo ago0 comments

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).

0 comments

bastawhiz3mo 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.

mdhb3mo 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.

j / k navigate · click thread line to collapse