3 ms·

Yes, it was what I feared, this to me is terrible news. I have experience with libraries running fake TS clones and then requiring an endless pile of type refac

by nawgz 5y ago

Yes, it was what I feared, this to me is terrible news. I have experience with libraries running fake TS clones and then requiring an endless pile of type refactoring if you need to extend it in some way. That said, I can understand one would want to use TypeScript and this in parallel, I just caution those going down this road that it is very easy to find yourself not really using TypeScript, and the second your TS doesn't compile with the official TS compiler, you are going to have upset users - and they might even be yourself! I for example quite liked ESBuild until I found situations where it didn't work, and then all those "instant" compiles were forgotten because I had to dig through esoteric, outside-of-my-expertise error messages and issues. Quick, type-safe hot reloading should be the target of course, but giving up type safety for speed is really not a good tradeoff.

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 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. 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.

by nawgz 5y ago

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 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. 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.