6 ms·

go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type

by forty 5y ago

go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.

eatonphil 5y ago
> 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.
apazzolini 5y ago
We use SWC with ts-node to strip types in dev for faster iteration loops and run the full tsc typechecker in CI (and optionally as a separate process on your local machine).
postalrat 5y ago
You compile ts without type checking when the options to do so are 10x+ faster than with type checking.
- pjmlp 5y ago
  I really don't get this, when I save my TS files they are already compiled into JS on the fly, ready to fed into a <script />.
  - recursive 5y ago
    By what? What if they were updated from an upstream repo, and never saved from an editor? What if you change branches without an upstream repo?
    - pjmlp 5y ago
      By VS and VSCode, the IDE/editor that belongs to the same company that does TypesScript. If I really need to call tsc explicitly, the few seconds that I have to wait, versus the minutes on some other languages, won't make me lose sleep over it.
mattkrick 5y ago
Personally, I let vscode do typechecking on open files & have a pre-commit git hook to typecheck changed files. When it comes to starting up a development server & building the client, there's a huge cost to repeatedly typechecking the same 1000+ files. By cutting out typechecking & only compiling, I can reduce the webpack client build from 40 seconds to 3 seconds (using sucrase).
- forty 5y ago
  I'm answering to you but this is really for most siblings: I maintain a fairly large TS code base (nodejs backend). I think a full rebuild is 1:30 on my relatively recent laptop (i7-8650U, lots of RAM). But in practice I always use tsc -w and compile is mostly instant after editing a file (I do have to wait whenever I launch the command after I boot, but after that, it's fast enough). tsc now support incremental compilation too, though I haven't played with it too much as I'm happy with watch mode.
  - rezonant 5y ago
    Incremental compilation is _okay_ but it seems to perform full rebuilds if the previous build is _too_ old which is weird- meaning that more builds than expected take the entire time to complete. Nonetheless I use it for all of my builds. On the other hand this may just be because of the spiraling nature of type inference, where TS needs to re-examine a large amount of the program from a change that appears simple. Personally I only have a small number of projects that take more than 10-20 seconds to compile, but those ones are painful. I should probably do the same with -w for those.
- morelisp 5y ago
  What if not everyone else on your team is paying attention to their editor's warnings? What if the LS's async response doesn't come fast enough? What if, god forbid, you have to change something on a different computer? If it's not in your CI/CD scripts, it's not actually getting checked. > I can reduce the webpack client build... to 3 seconds This is about 10x longer than any interaction with a computer should be.
bastawhiz 5y ago
If it takes one minute to type check a codebase and ten seconds to compile it to JavaScript, then whenever I simply need to produce a JavaScript file without type checking I'll save myself the fifty seconds. If my editor's TS language server does the checking and my bundler is just compiling for my dev environment, I don't want both tools duplicating each other's work.
forty 5y ago
Answering to myself, a colleague suggestion (from tsc doc actually): use tsc --noEmit (for type checking) and a fast compiler. tsc --noEmit duration is 2/3 of a normal build on our fairly large code base, so that can definitely speeds things up (for CI for example)

by forty 5y ago

go means it's going to be easier to integrate to esbuild :) I'm happy to see this, as honestly I don't really understand why you would compile TS without type checking.

eatonphil 5y ago

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

apazzolini 5y ago

We use SWC with ts-node to strip types in dev for faster iteration loops and run the full tsc typechecker in CI (and optionally as a separate process on your local machine).

postalrat 5y ago

You compile ts without type checking when the options to do so are 10x+ faster than with type checking.

pjmlp 5y ago
I really don't get this, when I save my TS files they are already compiled into JS on the fly, ready to fed into a <script />.
- recursive 5y ago
  By what? What if they were updated from an upstream repo, and never saved from an editor? What if you change branches without an upstream repo?
  - pjmlp 5y ago
    By VS and VSCode, the IDE/editor that belongs to the same company that does TypesScript. If I really need to call tsc explicitly, the few seconds that I have to wait, versus the minutes on some other languages, won't make me lose sleep over it.

mattkrick 5y ago

Personally, I let vscode do typechecking on open files & have a pre-commit git hook to typecheck changed files. When it comes to starting up a development server & building the client, there's a huge cost to repeatedly typechecking the same 1000+ files. By cutting out typechecking & only compiling, I can reduce the webpack client build from 40 seconds to 3 seconds (using sucrase).

forty 5y ago
I'm answering to you but this is really for most siblings: I maintain a fairly large TS code base (nodejs backend). I think a full rebuild is 1:30 on my relatively recent laptop (i7-8650U, lots of RAM). But in practice I always use tsc -w and compile is mostly instant after editing a file (I do have to wait whenever I launch the command after I boot, but after that, it's fast enough). tsc now support incremental compilation too, though I haven't played with it too much as I'm happy with watch mode.
- rezonant 5y ago
  Incremental compilation is _okay_ but it seems to perform full rebuilds if the previous build is _too_ old which is weird- meaning that more builds than expected take the entire time to complete. Nonetheless I use it for all of my builds. On the other hand this may just be because of the spiraling nature of type inference, where TS needs to re-examine a large amount of the program from a change that appears simple. Personally I only have a small number of projects that take more than 10-20 seconds to compile, but those ones are painful. I should probably do the same with -w for those.
morelisp 5y ago
What if not everyone else on your team is paying attention to their editor's warnings? What if the LS's async response doesn't come fast enough? What if, god forbid, you have to change something on a different computer? If it's not in your CI/CD scripts, it's not actually getting checked. > I can reduce the webpack client build... to 3 seconds This is about 10x longer than any interaction with a computer should be.

bastawhiz 5y ago

If it takes one minute to type check a codebase and ten seconds to compile it to JavaScript, then whenever I simply need to produce a JavaScript file without type checking I'll save myself the fifty seconds. If my editor's TS language server does the checking and my bundler is just compiling for my dev environment, I don't want both tools duplicating each other's work.

forty 5y ago

Answering to myself, a colleague suggestion (from tsc doc actually): use tsc --noEmit (for type checking) and a fast compiler. tsc --noEmit duration is 2/3 of a normal build on our fairly large code base, so that can definitely speeds things up (for CI for example)