As a js library maintainer and contributor, I do find these arguments flawed:
> There is a culture in the JavaScript community that “types don’t matter”
I don't think that's the case, particularly among seasoned developers: we do care about types and interfaces, but we just don't think writing them down in code is as big a deal as Typescript claims it to be.
> We are already linting because we believe it makes better code.
Linting doesn't require you to write non-javascript, it just works (after configurations). It doesn't force you to write code in any particular ways (see ESLint for example). That's why we find it more acceptable.
> Types are stronger. Types matter.
TS isn't automatically stronger, since TS is a superset of JS, developers can still omit the types. So you either write in proper TS-style and get its benefits, or don't.
And referring to earlier points:
> The types are there. Instead of leaving them implicit, you can just make them explicit.
IMO: there are many ways to setup this contract. And I question the % of type-related issues within a library when you have 100% test coverage and proper linting already.
> Often in JS libraries, the types are vaguely defined as an afterthought when writing docs.
TS can't force you to write strong types, just as JS can't force you to write good doc. You need a stronger will, not a better nag.
My case for writing your next popular library in vanilla JS: your users will already know how to contribute. And you get to choose how to enforce good variable types.
For TS vs JS details, see http://stackoverflow.com/questions/12694530/what-is-typescri...
Disclaimer: my libraries are nowhere as popular as angularjs or immutablejs, but I do intend to maintain them to a degree that may serve thousands of developers.
(Plus the author uses one of my library so I guess they are not that bad)