It only matters in a positive sense. Being written in TypeScript signals that it uses modern features that makes the code easier to read, that it doesn't use too many strange dynamic features, and of course that there are type definitions available for other TypeScript users. Other users can use it like they would use any JavaScript library.

No, because TypeScript can be compiled to JavaScript, so you can use the resulting library in plain JS. If you want to check the source of the library, then yes, you need to know TS.

"Knowing TypeScript" is...functionally trivial, though. If one can read JavaScript and can't get enough from context to read TypeScript, I question their knowledge of JavaScript!

Perhaps writing it is a bigger ask--a twenty minute session of reading and poking at the language in VSCode did it for me, but maybe I'm secretly some kind of TypeScript savant--but this just plain should not be a problem for anybody who's up on modern JS.

Well it does mean in order to understand the library and/or contribute you have to use <flavour of the month>. Also it makes the library prone to rewrites if something else comes up. I don’t mind TS (though es6 suits me fine) but I have seen many js paradigms come and go. Who knows maybe TS will stick around for the long haul.

Considering TS has been around since 2012 and has the full backing and support of MS since then I'd say calling it the flavor of the month is not necessary. Might they drop it some day? Maybe, but seeing as they have several large profile products using it that is unlikely any time soon.

Considering Typescript is a superset of javascript & the future of javascript - ie. they always plan to be implementing future javascript 'now', that is their whole reason for existence, and that their team sits on the javascript committee, then yes, I think it is around for the long haul. https://www.techtalko.com/2018/03/17/typescript-the-future-o...

This is a tired argument. SCSS was supposed to take over CSS... still waiting. For a hot minute, CoffeeScript was supposed to take over javascript. In the end, CoffeeScript didn't have a chance, but at the time many thought it did.

Typescript may be different and may be better, but there is a lot of rightly justified hesitation to adopting it.

Well SCSS took over CSS.

By what definition? Can I execute SCSS in modern browsers without needing to compile it?

As far as i know this was really never aim of the project. But everybody uses it. I would even say it oppened doors for JS compilation.. because everybody already has build process for css so why not js.

If TS does not stick around, it's very trivial to remove the types and put it back in plain JS, that's why even in the worst case scenario TS will not be a technical debt.

It does matter for the authors, with TS they would have probably needed another year or two to complete it.

They wrote it in TS. Don't know why you think it would take longer with TS. Personally, I prefer using TS as I'm faster with TS when the code is going beyond 1 file or O(10^2) LOC.

Agreed, and TypeScript's ease of writing code correctly and quickly is what finally got me away from Ruby and to Node almost all of the time. ES6 was legitimately nice and could have been good enough for about the 50%-75% case, but the ease of building expressive TypeScript typings that let the compiler tell me what I was screwing up without having to write insipid typechecking tests or repeatedly running scratch code sold me. And when I have to do something that TypeScript can't prove, it's very easy to just bail out, do my filthy misdeeds, and patch back into the type system after.

For awhile, React/Redux was really kind of gross with TypeScript, but even that's mostly hammered out. (React's new context API did a lot to reduce my use of Redux in general, and works pretty comfortably with TypeScript too.)