4 ms·

This is... good news, but I still cannot fathom using the default Typescript compiler for regular development. Seriously, leave the type-checking to your IDE a

This is... good news, but I still cannot fathom using the default Typescript compiler for regular development. Seriously, leave the type-checking to your IDE and CICD chain, and switch to using tsx (https://www.npmjs.com/package/tsx https://www.npmjs.com/package/tsx) or swc (https://swc.rs/ https://swc.rs/) and you will _immediately_ notice the difference in speed and productivity.

herpdyderp 3y ago
I wish there was also a much faster type checker!
- vlovich123 3y ago
  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)
  - duped 3y ago
    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.
    - vlovich123 3y ago
      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.
  - isanjay 3y ago
    I had a not so fast work laptop in my last work. Typescript compiler was very slow for relatively small project
- joshribakoff 3y ago
  Doesn’t the comment you just replied to link to one? (Tsx)
  - wffurr 3y ago
    No. It’s based on esbuild which does not check types.
jeroenhd 3y ago
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. Perhaps this is because I'm almost exclusively on Linux. tsc operates on tons of tiny files and Windows is notoriously slow at dealing with that, even with AV exclusions.
- DangitBobby 3y ago
  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.
- zastrowm 3y ago
  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.
rektide 3y ago
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.
- brundolf 3y ago
  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, but that's a much easier task Deno uses tsc internally, and VSCode at least uses the official typescript language server, which I believe uses tsc internally

herpdyderp 3y ago

I wish there was also a much faster type checker!

vlovich123 3y ago
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)
- duped 3y ago
  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.
  - vlovich123 3y ago
    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.
- isanjay 3y ago
  I had a not so fast work laptop in my last work. Typescript compiler was very slow for relatively small project
joshribakoff 3y ago
Doesn’t the comment you just replied to link to one? (Tsx)
- wffurr 3y ago
  No. It’s based on esbuild which does not check types.

jeroenhd 3y ago

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. Perhaps this is because I'm almost exclusively on Linux. tsc operates on tons of tiny files and Windows is notoriously slow at dealing with that, even with AV exclusions.

DangitBobby 3y ago
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.
zastrowm 3y ago
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.

rektide 3y ago

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.

brundolf 3y ago
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, but that's a much easier task Deno uses tsc internally, and VSCode at least uses the official typescript language server, which I believe uses tsc internally