I wish there was also a much faster type checker!

I have absolutely 0 problems with the type checking that VSCode does. Always feel snappy. By comparison, command line performance is absolute crap though. The missing piece I suspect is a background daemon that auto-analyzes as you type like they do when you’re editing in VSCode to hide that latency. That’s a pretty standard technique to solve this problem (typically LSC although I don’t know how VSCode does TypeScript)

I was almost 100% certain that the typescript language support in VSCode was using the typescript language service library that's also used by tsc.

Sure but the command line version as best I can tell doesn’t bother keeping a long-lived tsc around. Sure, you can run it in watch mode but if you just run it it doesn’t bother doing that. For example, Facebook launches watchman to keep track of file modifications to files and keeps Buck’s dependency graph up to date so that Buck knows which targets are out of date instantly when you run the command. A more advanced version would know which targets you rebuild/run when you make a change like that and automatically refresh them. Same for running the tests.

I had a not so fast work laptop in my last work. Typescript compiler was very slow for relatively small project

Doesn’t the comment you just replied to link to one? (Tsx)

No. It’s based on esbuild which does not check types.

Leaving type checking to the IDE can cause a lot of unforseen problems. IDE support is imperfect, especially if you have some legacy JS code you need to integrate with, and sometimes it's even unreliable.

The Typescript transpiler does definitely slow things down but I've tried the "only check types during build" approach and while it starts out very nice and quickly, you end up wasting all that time you would've waited on tsc by chasing down impossible to find typing bugs and doing the necessary code restructuring to fix the problems your IDE missed. Only finding out about these bugs when pushing code (or even worse, when opening a pull/merge request) can be a lot more annoying than giving tsc half a second to catch up.

I do wish that tsc was faster, but on the other hand I can't say it's been that much of a problem for me.

YMMV. I very rarely have the IDE and tsc disagree. Even though it happens occasionally, I'd much rather have instant type feedback as I work and have to fix some errant types with 10s+ feedback right before checking in than have 10s+ feedback all the time.

I find the best middle ground is setting up the IDE to have TSC watch running while making changes, but using other tools for doing the actual compiling (vite for example). This allows me to refactor quickly - choosing when to ignore type errors - but also be notified of all the other call sites that I need to update, including in all of the files not currently open in the editor.

I just have such a hard time imagining how the other type checkers keep parity.

TypeScript doesn't evolve super fast, but there are a steady stream of great improvements. I'd be so afraid I have either less type checking, things that silently pass/aren't checked, or intelligence that TypeScript has that other checkers don't have.

Also, as others say, just using --watch largely eliminates the problems of using tsc. I haven't worked on any truly huge codebases but it's been quite snappy. It's a longshot, but I wish TypeScript would also be it's own LSP too.

I definitely did love love love how blazingly fast & super easy to work with, no setup, Deno was. Incredibly refreshing, no ceremony.

They don't keep parity. As far as I know, the official TypeScript implementation is the only major one that performs checking. There are tons of other options for stripping types that are much faster than it, but that's a much easier task.

VSCode at least uses the official checker under the hood; I believe Deno does to, and I would expect IDEA to use it too