Comment by AirMax98
2 years ago
As someone who regularly writes both JS and TS, I'm fairly certain that this dichotomy is not real. There are places where TS makes more sense (eg large, trustless applications with many devs) and places where JS makes more sense (eg libraries that would otherwise need to have very abstract types).
I'd understand opting for either JS or TS as a policy going forward, but it's hilarious that this dude probably worked himself up so intensely about this that he brazenly rug-pulled his own repo and invalidated all open PRs.
> places where JS makes more sense (eg libraries that would otherwise need to have very abstract types)
If your library is hard to type, it is a code smell. In my opinion, such libraries could benefit from TS a lot.
libraries if they are popular in general are expected to work with a wide variety of code. Supporting code smell is a feature.
Can you share some examples of libraries you feel benefit from this sort of unlimited flexibility?
1 reply →
variety of code is one thing, your library can be used in thousands of places, doesn't mean it have to do thousands of different things
I don't think the dichotomy exists because the TS ecosystem is autonomous. You can use TS with any JS library through type declarations and the definitely typed repo. What the js community thinks about typescript honestly doesn't matter. The only practical difference it makes for me is having to do `npm add @types/{library_name} -D`