No, it's because TS adds information. Pure JS doesn't know what variable "foo" is (is it a potato? is it an array? can it be null?), but if you assign it a type like Map<string> then now it knows what kind of data it can hold, what you can do with it, etc. Now you know you can do foo.get() and your IDE will tell you as soon as you've typed `foo.`, but if you used pure JS, lol how is it supposed to have any idea what methods exist?

It lets you chain data from one task to another based on knowing what possible and available given the types. That information just straight up doesn't exist in JS code, unless you write JSDoc comments all over with that information as static analysis hints. But why not just embed that information in the language itself instead of tacking it at the top of every chunk of code, much more elegant and allows way more power.

Even if you used JSDoc, you still need that static analysis tool to exist, and hey, that's exactly what TypeScript is. It's both a language definition for augmenting JS with types, but it's also a transpiler which takes TS code and spits out JS code, _and_ it will tell you if there's problems with the types. But since that engine exists, you can plug it into LSP and so on.

Remember, LSP exists _because_ of TypeScript. VSCode exists because of TypeScript. The team that works on VSCode and came up with LSP did it because they wanted TypeScript to integrate with VSCode and they had the foresight to build something generalized that could be used for ANY language.