Hacker News Reader

Comment by rtpg | Hacker News Reader

TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)

View on HN

PS: swc and esbuild aren't good example, because most of the speed improvements comes from the fact that they are just stripping TS-specific syntaxes to generate JS code.

Also tsc is slow, sure, but only for the first run. Enabling `incremental` flag or using watch mode with `--transpile-only` usually brings compile time under 100ms, Making it practically indistinguishable from SWC or ESBuild.

There's an answer from TypeScript team for your question :) https://twitter.com/drosenwasser/status/1260723846534979584

Basically,

> Let's say TypeScript takes over 20 seconds to type-check a medium-sized program. That's not usually because it's JS, it's often because of types that cause a combinatorial explosion.

Also

> A different runtime can afford a lot (it sounds like parallelism and start-up time in this case) but I haven't seen a CPU-bound benchmark that supports the idea of a 20x all-up speed-up.

Both swc and esbuild claim to be much faster typescript compilers in part because they're written natively, but are actually just "cheating" and not doing any type-checking at all.

That's not to say they're useless though, they're good for fast hot-reload as you can have type-checking running in parallel.

it's easy to write a typed language compiler if you don't need to actually check types :)

I mean I get what Daniel's saying, but I kinda doubt there wouldn't be _some_ speedup. And hey, what if type checking for small programs went from half a second to 100 ms? That would be nice!

That's a five times speedup. I wouldn't expect a typical 'compiled' language to run five times faster than JavaScript on the kind of code you find in a compiler.

You are excluding startup time. Loading the interpreter/runtime and initial JIT pass is slow. For many codebases, the compilation time is actually dominated by the time it takes the interpreter to get going.

The type system is fun right up until you are using it to its full ability in generics..then you look at the 5 lines of 'type logic' you spent the last day debugging and ask yourself how you got here.

I've definitely seen it suck people into a black hole. It works best when you think of it as a form of documentation with a benefit of enforcement, rather than trying to use the type system to prevent every conceivable bug. Massive unreadable types don't help programmers write better code.

Pretty true lol chaining something together that ends up looking like this:

<<<<<<<<T>>>>>>>>

Is basically a guaranteed headache

Wonder no more: https://github.com/dudykr/stc

Written in Rust by the (lead?) dev of SWC

---

SWC (speedy web compiler) compiles TS to JS

STC (speedy type checker) checks TS types

Performance of the TypeScript compiler has greatly improved in the last versions. The future isolated declaration mode promises great improvements: until 75% of reduction in compilation time! [0]

[0] https://github.com/microsoft/TypeScript/pull/53463#issuecomm...

Probably not that much faster. V8 is very good at optimizing JS code. Typescript is slow mostly because of the complexity of its type system (which is required to make it backward compatible with existing JS code).

Probably quite a bit faster if you do not have to instantiate a new V8 for every single file, considering how many files your average npm project has. I'm not certain if any contemporary build systems reuse the compiler process for multiple files

Why would it have to instantiate a new V8 for every file? You can just run 'tsc' in your project dir to compile all Typescript files.

I think people often underestimate how much the TypeScript team does to make TypeScript fast and efficient. They have some of the best people in the field working on the type checker

Indeed. I haven't checked the implementation, but I suspect that "don't spin up a separate process for every file" is an idea that has probably already occurred to them :D

Yes, because it's one of the slowest compilers in the world, and its job is to compile from JavaScript to JavaScript. There are other languages with complex type systems, where the compilers have to do a lot of other additional work on top of typechecking, and are still way faster than TS.

And TypeScript is always slow, not only when you do abuse its type system and require it to do complex inference - I mostly use it for "this is a number" and "this is a object with the following 4 fields" and it's still by far the slowest component in my builds usually

I haven't used it in a couple of years (tbh I may have to remove "full stack" and "Angular" from my CV...) but I don't recall TS compilation being particularly slow. Are people not happy with how quick it is, or do you have a particularly big/complex application you're working with?

Notion is more than 10k typescript files and we view typecheck slowness and memory pressure as an existential threat to our codebase. Right now our typecheck needs ~12GB of heap size but the memory needs have accelerated recently.

NX likely would do magic for you all but I imagine it is far too late to do anything about that.

We had a very large Angular 10 project that we replaced with an NX Angular project late last year. We went from ~6 minute prod compile to around 20 seconds, recompile is lightning fast because it only builds your affected library. That is all without using the remote library cache feature where you can save compiled libraries to the cloud such that a user only builds the libraries they are changing ever.

Can you not split the 10k files into modules for incremental/parallel compilation?

There’s https://swc.rs/, a Rust implementation (albeit without type checking at this time).

Not really a fair comparison. Stripping out types is trivially fast regardless of the implementation language. The _vast_ majority of the time taken in tsc is because of the type checking

See the sibling comment https://news.ycombinator.com/item?id=37173313 for a type checker by the same author.

> part of me always wonders how much faster TS's compiler would be if it was written in a compiled language

TypeScript's compiler _is_ written in a compiled language.

(I think you are using "compiled" here as a euphemism—one that doesn't help anyone.)

The reason we need to buy new hardware every few years, and fill landfills with our old stuff, is because of ideas like “let’s use JavaScript to write a compiler!”

No lie, the M1 was a game changer for large Typescript projects.

Reply on news.ycombinator.com