3 ms·

> I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking. I don't think I'm remotely alone in doing this b

> I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking. I don't think I'm remotely alone in doing this but I'll share from my perspective. I have two modes while writing TypeScript stuff: 1) prototyping something where I don't want to spend time writing types (or maybe I write some types but I don't care if they are correct or line up yet) but I still want to have JavaScript generated so I can test the thing out manually and 2) getting types correct as part of long-term maintenance and edge-case removal. There are fast TypeScript -> JavaScript generators today like swc and esbuild. tsc is not fast. So I can speed up "1)" from above if I use swc and esbuild and only use tsc for "2)" from above. As people write faster implementations of tsc-the-type-checker though I'll be happy to use that instead and just not use tsc anymore.

m-hilgendorf 5y ago
> 1) prototyping something where I don't want to spend time writing types It doesn't compile to JS, but this is one of the canonical use cases for Stanza 's (1) "optional" type system (1) http://lbstanza.org/optional_typing.html http://lbstanza.org/optional_typing.html
tshaddox 5y ago
Out of curiosity, how often do you have a project in the first mode that gets large enough that the speed of compiling TS to JS is significant?
- eatonphil 5y ago
  There is a huge difference even in small and mid-size projects. https://datastation.multiprocess.io/blog/2021-11-13-benchmarking-esbuild-swc-typescript-babel.html https://datastation.multiprocess.io/blog/2021-11-13-benchmar...
- nicoburns 5y ago
  If you're writing UI code then even a few seconds is slow. You don't want to be waiting 5 seconds every time you move something a couple of pixels to the left.
forty 5y ago
That makes sense, I would generally use JS directly for mode 1), but I understand the use case.
mixedCase 5y ago
Have you tried doing Type-Driven Development? IME, most of the time constraints are determined through types first with the code being done later tends to replace the game of "what kind of complex and non-obvious types fit my code the most" with a "oh, the implementation is obvious" reaction. It also makes it easier to determine what behavior is worth testing and which ones are already covered by your types, if you tend to write tests last. If instead you're used to Test-Driven Development you can do types->tests->code.
- eatonphil 5y ago
  I've spent a lot of time programming in Standard ML and yeah that's a prerequisite there. But no I don't prefer it to what I do in TypeScript.

m-hilgendorf 5y ago

> 1) prototyping something where I don't want to spend time writing types It doesn't compile to JS, but this is one of the canonical use cases for Stanza 's (1) "optional" type system (1) http://lbstanza.org/optional_typing.html http://lbstanza.org/optional_typing.html

tshaddox 5y ago

Out of curiosity, how often do you have a project in the first mode that gets large enough that the speed of compiling TS to JS is significant?

eatonphil 5y ago
There is a huge difference even in small and mid-size projects. https://datastation.multiprocess.io/blog/2021-11-13-benchmarking-esbuild-swc-typescript-babel.html https://datastation.multiprocess.io/blog/2021-11-13-benchmar...
nicoburns 5y ago
If you're writing UI code then even a few seconds is slow. You don't want to be waiting 5 seconds every time you move something a couple of pixels to the left.

forty 5y ago

That makes sense, I would generally use JS directly for mode 1), but I understand the use case.

mixedCase 5y ago

Have you tried doing Type-Driven Development? IME, most of the time constraints are determined through types first with the code being done later tends to replace the game of "what kind of complex and non-obvious types fit my code the most" with a "oh, the implementation is obvious" reaction. It also makes it easier to determine what behavior is worth testing and which ones are already covered by your types, if you tend to write tests last. If instead you're used to Test-Driven Development you can do types->tests->code.

eatonphil 5y ago
I've spent a lot of time programming in Standard ML and yeah that's a prerequisite there. But no I don't prefer it to what I do in TypeScript.