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.

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

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

> 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

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.

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

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.

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