[pauliusj]

My only wish is that the compile times were faster. I know typically people will say there's incremental compilation, but I think this problem leaks into many other places. Like vscode suggestions, go to definition, custom build scripts for which you may need to process types etc. I recently had to use eclipse for some java work and it seemed lightning fast in comparison. This is my only (pretty big) complaint about TypeScript, otherwise it's a very useful tool

[koolba]

If you separate compilation from type checking, the compilation stage is instant. If it’s not, spend the hour or so to understand how to rework your tooling so that it’s working properly. It’ll pay off by the end of the same day.

[aconbere]

I have to admit i’m baffled by this suggestion. I get that compilation and type checking offer different value propositions, but i’ve now walked into a couple of projects that were happily compiling their typescript with babble only to realize once compiling with tsc that there were rampant type errors.

I find this idea of throwing away safety for compilation speed to be a non-option.

[lewisl9029]

Decoupling build and typecheck is definitely a good first step, but poor typecheck performance is still going to eventually become a bottleneck in CI as project sizes increase.

At Brex we were running up against typecheck times of over 15 minutes at one point before we were forced to address it since it was frequently creeping onto the critical path. We ended up hacking together some CI scripts to share the incremental typecheck cache between builds, which made most checks reasonably fast again (usually well under a minute, averaging 10~ seconds), but there are still frequent large spikes (of 5-15 minutes) in typecheck times on tiny, seemingly innocent changesets (with few dependent files as far as we could tell) that can still really take a toll on productivity.

I believe the recommended solution to scale typecheck performance is to break down your app using interdependent project references that serve as atomic units that only get rechecked if they change, but I'm personally not a fan of this approach because most frontend projects don't really derive any intrinsic benefit from this style of organization (as they function perfectly fine as monoliths, and any added indirection only adds unnecessary friction), and project references themselves have a bunch of caveats and introduce a ton more tooling complexity: https://www.typescriptlang.org/docs/handbook/project-referen...

I wish instead of having to break down our apps into project references manually to reap the performance benefits, TypeScript could just treat each file as a "project" onto itself and give us those performance benefits automatically and by default. In the ideal world I should be able to just run `tsc --noEmit` with the list of files changed from git, and have typescript do the minimum possible amount of work to check all the potential files affected by the changed input files by walking up their dependency graphs, without having to structure my project in a certain way.

[pauliusj]

It's late here, looks like I did a few wording mistakes. The actual compilation (turning ts/tsx into js) is very fast and not a problem at all, what I meant is the typechecking

[rpastuszak]

Interesting, I'm generally quite sensitive to small delays when typing/seeing autocomplete, but this hasn't been much of an issue for me, even in VSCode. But maybe that's because I only enable extensions on a per-workspace basis.

Regarding build times, have you tried using esbuild (https://esbuild.github.io)? It's ridiculously fast.

vitejs uses it in their dev mode (https://vitejs.dev) if you wanna give it a shot without spending too much time fiddling with configuration.

[remorses]

The creator of SWC [0] is working on a faster compiler alternative in Rust, so there is still hope for a faster compilation speed in the future

[0] https://github.com/swc-project/swc

[IshKebab]

SWC doesn't do type checking, which means 99% of the work is just stripped type annotations. That's why it's fast.