3 ms·

The most pragmatic reason to use TypeScript is for gradual typing of existing codebases, and that all JavaScript is valid TypeScript. You can introduce TypeScri

The most pragmatic reason to use TypeScript is for gradual typing of existing codebases, and that all JavaScript is valid TypeScript. You can introduce TypeScript over time and if it doesn't work out for your group, you can delete the TypeScript-specific annotations and go back to Babel. Or you can keep TypeScript to only specific parts of your application/library. The most pragmatic reason not to use TypeScript is because it is static-only. And that is easy to forget. That is, within any arbitrary function X you have no guarantee the parameters passed to X are the type specified in TypeScript. There isn't a ton you can do about this except for to code very defensively where it matters. I've used TypeScript for a number of projects professionally, introducing it among developers familiar and unfamiliar with static typing. I'm not really interested in going back or finding alternatives for now. It is a huge help in development and refactoring without a huge cost.

siempreb 7y ago
> and if it doesn't work out for your group, you can delete the TypeScript-specific annotations and go back to Babel. You are joking right? Ever tried to do that with a large Typescript code base and then of course without the defensive strategy? It's a myth Typescript proponents really enjoy to believe. > There isn't a ton you can do about this except for to code very defensively where it matters. Bingo! That's what I always did and served me well on very large code bases. With Typescript I have to write about 20% more code(that can hide bugs too). Advantage? A bit more intellisense than VScode gives already out of the box, and of course for the junior and medior developers so they cannot mess up(types).
- eatonphil 7y ago
  > Ever tried to do that with a large Typescript code base and then of course without the defensive strategy? It's a myth Typescript proponents really enjoy to believe. You got me. I have not tried to do this in a large TS codebase. > There isn't a ton you can do about this except for to code very defensively where it matters. Of course you have this issue in pure JavaScript too. So it's not so much that TypeScript is worse it's just not as big an improvement in this regard as a compile-to-JavaScript language that gives you runtime type safety.
- wwwigham 7y ago
  It's probably worth noting that that the "intellisense that vscode gives out of the box" is _also_ still delivered by TypeScript. Slap a `//@ts-check` into a js file and you'll find just where the typechecker thinks your jsdoc or usages are lacking or confusing (then maybe add a jsconfig with stricter settings than the default!). If you then fix those, you should be capable of getting _nearly identical_ completions in js and ts (because they really are just variants of the same language). IMO, TS is all about static enforcement of inline documentation (types), just like how a linter enforces style. You can choose not to enforce it automatically... But at this point I don't get why you wouldn't? I wouldn't argue that style enforcement is best done by hand in the code review stage... So I don't see how further quality checks based on semantics derived from documentation would be any different.
hajile 7y ago
In order to interopt, you're going to be using `any` a lot of places. You then have the illusion of sound types. You have all the extra work of sound types. But you do not have sound types and should not be relying on them.
- eatonphil 7y ago
  > In order to interopt, you're going to be using `any` a lot of places. This is not true. Types may be complex and out of laziness (which we do suffer from) there may be `any` types laying around. But you can set up eslint rules that forbid this and turn off implicit `any` at the TypeScript compiler level so you aren't bit by the defaults (which are not nice, for sure). We have very few `any`'s now in our code and aim to get rid of all of them.
  - WorldMaker 7y ago
    The new-ish `unknown` type is also very useful for interop work to force adding runtime checks where needed. Some of the Typescript defaults are slowly moving to `unknown` rather than `any` in the strictest compile modes.
  - hajile 7y ago
    If you turn off `any` on a gradually-typed codebase, everything will blow up because of the untyped parts. Gradual typing CANNOT be sound unless you dynamically typecheck everything (at which point you are just doing what JS devs do anyway).
    - eatonphil 7y ago
      > If you turn off `any` on a gradually-typed codebase, everything will blow up because of the untyped parts. Again, that's not true. A JavaScript file's exports don't have `any` type. Any types during interop are inferred (maybe?) or require bindings. The use of `any` in bindings is your (sometimes valid) choice. > Gradual typing CANNOT be sound TypeScript isn't sound [0]. [0] https://github.com/Microsoft/TypeScript/issues/9825 https://github.com/Microsoft/TypeScript/issues/9825

siempreb 7y ago

> and if it doesn't work out for your group, you can delete the TypeScript-specific annotations and go back to Babel. You are joking right? Ever tried to do that with a large Typescript code base and then of course without the defensive strategy? It's a myth Typescript proponents really enjoy to believe. > There isn't a ton you can do about this except for to code very defensively where it matters. Bingo! That's what I always did and served me well on very large code bases. With Typescript I have to write about 20% more code(that can hide bugs too). Advantage? A bit more intellisense than VScode gives already out of the box, and of course for the junior and medior developers so they cannot mess up(types).

eatonphil 7y ago
> Ever tried to do that with a large Typescript code base and then of course without the defensive strategy? It's a myth Typescript proponents really enjoy to believe. You got me. I have not tried to do this in a large TS codebase. > There isn't a ton you can do about this except for to code very defensively where it matters. Of course you have this issue in pure JavaScript too. So it's not so much that TypeScript is worse it's just not as big an improvement in this regard as a compile-to-JavaScript language that gives you runtime type safety.
wwwigham 7y ago
It's probably worth noting that that the "intellisense that vscode gives out of the box" is _also_ still delivered by TypeScript. Slap a `//@ts-check` into a js file and you'll find just where the typechecker thinks your jsdoc or usages are lacking or confusing (then maybe add a jsconfig with stricter settings than the default!). If you then fix those, you should be capable of getting _nearly identical_ completions in js and ts (because they really are just variants of the same language). IMO, TS is all about static enforcement of inline documentation (types), just like how a linter enforces style. You can choose not to enforce it automatically... But at this point I don't get why you wouldn't? I wouldn't argue that style enforcement is best done by hand in the code review stage... So I don't see how further quality checks based on semantics derived from documentation would be any different.

hajile 7y ago

In order to interopt, you're going to be using `any` a lot of places. You then have the illusion of sound types. You have all the extra work of sound types. But you do not have sound types and should not be relying on them.

eatonphil 7y ago
> In order to interopt, you're going to be using `any` a lot of places. This is not true. Types may be complex and out of laziness (which we do suffer from) there may be `any` types laying around. But you can set up eslint rules that forbid this and turn off implicit `any` at the TypeScript compiler level so you aren't bit by the defaults (which are not nice, for sure). We have very few `any`'s now in our code and aim to get rid of all of them.
- WorldMaker 7y ago
  The new-ish `unknown` type is also very useful for interop work to force adding runtime checks where needed. Some of the Typescript defaults are slowly moving to `unknown` rather than `any` in the strictest compile modes.
- hajile 7y ago
  If you turn off `any` on a gradually-typed codebase, everything will blow up because of the untyped parts. Gradual typing CANNOT be sound unless you dynamically typecheck everything (at which point you are just doing what JS devs do anyway).
  - eatonphil 7y ago
    > If you turn off `any` on a gradually-typed codebase, everything will blow up because of the untyped parts. Again, that's not true. A JavaScript file's exports don't have `any` type. Any types during interop are inferred (maybe?) or require bindings. The use of `any` in bindings is your (sometimes valid) choice. > Gradual typing CANNOT be sound TypeScript isn't sound [0]. [0] https://github.com/Microsoft/TypeScript/issues/9825 https://github.com/Microsoft/TypeScript/issues/9825