Typescript has `interface` and `class` which is needlessly confusing
Java and C# have had a distinction between `interface` and `class` for decades. It shouldn't be that confusing? One describes a shape or a contract of an object and the other an implementation of a kind of object (which in turn might support multiple interface shapes/contracts). It's not something unusual to OOP languages with type systems. Perhaps the only thing to complain about Typescript interfaces is that they are far more on the shape side of things than the contract side of things, and it is tough to rely on them if you want more of the contract semantics (because the language can't enforce that contract).
It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive
Typescript gets as comprehensive as you want it to be. It's set of checks is an onion design to allow for various control needs, especially because projects may need to opt-in to only some of the checks in order to ease migration. If you want all the checks the flag to pass isn't `--noImplicitAny` it is `--strict` (or in tsconfig.json, "strict": true). I recommend that for all greenfield projects and most brownfield projects if they don't mind fixing lots of compile errors (for the betterment of their project).
Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct
Not all type information is from DefinitelyTyped anymore, and in many ways DT is smaller than it was at its peak. More and more libraries on npm themselves are written in Typescript and provide their own type information fresh out of the Typescript compiler itself. Even libraries that aren't written in Typescript are taking maintenance ownership of their Typescript types themselves and sometimes the JS authors are right there critiquing their own types.
There will always be a mismatch between untyped JS and what Typescript types represent of that world, but it is better than it used to be, and better all the time.
Comments
Java and C# have had a distinction between `interface` and `class` for decades. It shouldn't be that confusing? One describes a shape or a contract of an object and the other an implementation of a kind of object (which in turn might support multiple interface shapes/contracts). It's not something unusual to OOP languages with type systems. Perhaps the only thing to complain about Typescript interfaces is that they are far more on the shape side of things than the contract side of things, and it is tough to rely on them if you want more of the contract semantics (because the language can't enforce that contract).
Typescript gets as comprehensive as you want it to be. It's set of checks is an onion design to allow for various control needs, especially because projects may need to opt-in to only some of the checks in order to ease migration. If you want all the checks the flag to pass isn't `--noImplicitAny` it is `--strict` (or in tsconfig.json, "strict": true). I recommend that for all greenfield projects and most brownfield projects if they don't mind fixing lots of compile errors (for the betterment of their project).
Not all type information is from DefinitelyTyped anymore, and in many ways DT is smaller than it was at its peak. More and more libraries on npm themselves are written in Typescript and provide their own type information fresh out of the Typescript compiler itself. Even libraries that aren't written in Typescript are taking maintenance ownership of their Typescript types themselves and sometimes the JS authors are right there critiquing their own types.
There will always be a mismatch between untyped JS and what Typescript types represent of that world, but it is better than it used to be, and better all the time.