You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time.

These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer.

(For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)

Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue.

But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.

I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.)

The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing).

I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.

Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.

    const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBar

When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.

Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-7...

The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.

Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.

Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening.

Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.

Or just to the developer that likes to offload that cognitive load to their tools.

Why hold that in my head when the IDE can keep track of it for me? Why memorize every single attribute name when the IDE can autocomplete it for me? etc.

Instead keeping track of the type annotation in your head, and then also keeping track of the rest of the stuff in your head too.

If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result.

Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster.

"Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types.

My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript.

Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"

Yeah, they're optional, but if you don't write them, there's no point in using TypeScript in the first place.

2) If the types can be inferred, that should just happen. No objection there. But this piece is specifically about "adding (manually-authored) type annotations to JavaScript"