5 ms·
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, trust
by AirMax98 3y 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.
- etler 3y agoI 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`
- LudwigNagasena 3y ago> 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.
- muxr 3y agolibraries if they are popular in general are expected to work with a wide variety of code. Supporting code smell is a feature.
- Destiner 3y agovariety 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
- seattle_spring 3y agoCan you share some examples of libraries you feel benefit from this sort of unlimited flexibility?
- PH95VuimJjqBqy 3y agojquery