4 ms·

Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance p

Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?

danielheath 2y ago
> a significant performance penalty with typescript There's a significant performance penalty for using javascript outside the browser. I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance tooling for go is dramatically more mature.
- sapiogram 2y ago
  > I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.
salmonellaeater 2y ago
No. You seem to be referring to runtime performance of compiled code. The announcement is about compile times; it's about the performance of the compiler itself.
Cthulhu_ 2y ago
Nope; 'compiling to javascript' is a relatively trivial operation, just remove the type information. This is what Babel and nowadays NodeJS itself are doing. What is more important is that tsc does typechecking, which is a static analysis of sorts to ensure code correctness. But this has nothing to do with runtime performance, that's entirely in JS land and in JS transpilers / optimizers.
crabmusket 2y ago
I don't think anyone uses JavaScript for speed. Dynamic or scripting languages have been making this tradeoff since... as long as there has been programming?

danielheath 2y ago

> a significant performance penalty with typescript There's a significant performance penalty for using javascript outside the browser. I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance tooling for go is dramatically more mature.

sapiogram 2y ago
> I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.

salmonellaeater 2y ago

No. You seem to be referring to runtime performance of compiled code. The announcement is about compile times; it's about the performance of the compiler itself.

Cthulhu_ 2y ago

Nope; 'compiling to javascript' is a relatively trivial operation, just remove the type information. This is what Babel and nowadays NodeJS itself are doing. What is more important is that tsc does typechecking, which is a static analysis of sorts to ensure code correctness. But this has nothing to do with runtime performance, that's entirely in JS land and in JS transpilers / optimizers.

crabmusket 2y ago

I don't think anyone uses JavaScript for speed. Dynamic or scripting languages have been making this tradeoff since... as long as there has been programming?