[redmorphium]

Some Typescript value added:

- Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain.

- Better tooling: autocomplete, more robust auto-refactoring

- Elimination of an entire class of bugs. This class may include: 1. `Cannot read property 'foo' of undefined` 2. forgeting a case in a switch statement 3. `'foo' is not a function` 4. in general, your code receiving data that isn't laid out in a way you expected

(Property typos is one within this class of bugs, but it is not all of it)

Yes tests catch these bugs as well. But tests are also manually written. And often not written at all. A compiler makes these (mundane) sanity checks automatic and mandatory.

---

Typescript's slogan is "JavaScript that scales" because static typing improves: dev documentation (via types living inside the code) and dev tooling (refactoring and autocomplete), both of which help immensely as a project grows in age (devs become forgetful), team size (new developers get lost), and convolutedness (e.g. tech debt).

[kjtekn]

Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know!

auto-refactoring.. yeah we all trust that. Until you come to the boundaries where all the types don't exist, like from the client to the server, to the database via its message system, etc. All the stuff coming in and out of your code is untyped.

Autocomplete works without typescript, even if it uses "the typescript engine". The types aren't needed.

Eliminates an entire class of bugs that nobody has ever had a problem with.

[JoeyJoJoJr]

I get the impression you either don’t have much experience with Typescript or haven’t fully grokked it’s workflow, and have prematurely made up your mind. Your autocomplete comment for instance shows you aren’t aware of the extent to which Typescript vastly improves autocomplete.

Regarding typing at the boundaries, this is precisely where typescript shines. The types exist whether they are documented explicitly in your code (in the form of interfaces, types, protocols, etc), or not. This is where the documentation aspect come in to play - it is far easier to read a type definition than having to chase up API documentation, mentally parse tests, or console logging out api responses, to understand your boundary. Your refactoring argument is a strawman, because you wouldn’t just go and refactor names of things at the boundaries of your code in typescript, or any other language, without understanding the API spec. What typescript gives you is precisely the ability to refactor at the boundary when the spec changes and be much more confident that your changes aren’t going to break a whole bunch of thing, especially when it comes to the “class of bugs” that literally every JavaScript developer has dealt with, whether you are aware of them or not.

[eatonphil]

> All the stuff coming in and out of your code is untyped.

Until you automate building TypeScript definitions from your external code. We do this to varying degrees and are always trying to improve.

[vhakulinen]

> TypeScript is less readable.

What makes you say so? I find it more readable than javascript.