3 ms·
The existence of a fast type-stripping compiler like swc just means that people would use `tsc` to only type-check, then use swc to compile to JS. The expectati
by Arnavion 5y ago
The existence of a fast type-stripping compiler like swc just means that people would use `tsc` to only type-check, then use swc to compile to JS. The expectation being that the cost of invoking swc is outweighed by it being faster than tsc's emit and/or generating better output. TS is already designed around having the type-checking and the JS output be completely independent, so `tsc` cannot do a better job than an external compiler in regards to the quality of the generated code.
In other words, instead of `tsc` you run `tsc --noEmit && swc`
You still need to know about the actual types in the program, and you still need to run them through `tsc` first regardless of whether `swc` accepts them or not.
- nawgz 5y agoSimply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. I don’t really see the value in weakening your type safety and compiler guarantees in exchange for 100ms compile time.
- Arnavion 5y ago>Simply put, compiling code that does not pass the type checking is a waste of cycles, and I have seen footguns in this way. Nowhere in my comment did I say that.
- nsonha 5y ago> code that does not pass the type checking is a waste of cycles no, have you ever done hot reload in front-end development? When you make a typo on a type definition do you want tsc to bail & the whole application state to be lost? I guess CPU cycles are more valuable than your time? edit: btw tcs does NOT bail, so your argument is moot because the typescript compiler itself "wastes cycles" like that. > weakening your type safety nothing is "weakened" here, what happens is, people can continue to work/test different parts of the codebase without having the full project type-checked out.