Context matters. Some people, while writing their own application code, find types to be annoying, a nuisance, or whatever. That's a personal (or team) decision.

This article is targeted at authors and maintainers of high-adoption libraries. It says so right in the second paragraph.

And, frankly (speaking as someone with experience on this topic), he's right. Maybe static isn't always the answer, but in the context of high-adoption libraries, a little bit of effort to improve clarity and strictness is a huge lever for cutting down on wasted time of thousands of developers everywhere.

> The article doesn't really offer up any real arguments as to why you should specifically use TypeScript

Did you read it? He offers the Git/Mercurial comparison of TypeScript's growing popularity.

He mentioned "contracts." You can throw off the shackles and use the `any` type internally, but at the very least your public interface should have a well-defined contract. TypeScript is one [very good] way to achieve that and it even spits out machine-readable "contract summaries" for you (.d.ts files).

I may choose not to document my code or not to test it - because it's just a one-time script, because it's going to be thrown away soon, because all my coworkers know what the code does... It's more than debatable of course, but it happens a lot in practice. However, if I write a piece of code that will be re-used a lot (inside my company, by friends...), I will do more of that (tests, documentation). I expect the same from libraries authors, whose explicit goal is to be re-used by others. The author's point is that typings is similar to tests and documentation - if you want people to use your projects, typings will help them (it actually serves as a good start for tests - catching bugs that cause compilers errors / warnings - and documentation - what your functions accepts is a very good start), and it adds eg. autocompletion / 'go to definition'. As a user, feel free to use Typescript or not. As a library author, help your users by using types.

The point the author is trying to make is that all Javascript libraries should be annotated with types. Not necessarily Typescript, but that's the popular choice right now.

I think the core of the argument is this:

> some type definitions are better than none. It may be quite feasible to build conversions from .d.ts to FlowType type definitions or other languages type definitions, so whatever the Future of Typed JavaScript will be, having .d.ts files today will help us in the future to migrate towards it.

So I read the argument as "Give me at least slightly automatically verifiable api with your library".