2 ms·
The argument feels like it started from a pre-existing conclusion (not liking/knowing TS) and retrofitting a reason (supposed fragmentation). The reality is th
by lhorie 6y ago
The argument feels like it started from a pre-existing conclusion (not liking/knowing TS) and retrofitting a reason (supposed fragmentation).
The reality is that NPM is already a fragmentation mess. There are many libraries that break because of things like poorly tested `module` field in package.json and/or .mjs support. There are libraries that break with different versions of node, or different package managers, or different OSes, libraries that only work with webpack and/or babel (and/or react/vue/[insert framework here]). There are libraries that break with random transitive pins because who tests that every permutation within a semver range is actually following semver correctly. There are libraries with broken CI because it's in "maintenance mode" for years but the travis setup is stuck 5 major versions of Node behind. There are abandoned libraries, libraries that drop support for browsers on minor bumps, and libraries with hostile maintainers. There are libraries written in clojurescript and nim and reason. There are libraries written with other type systems (e.g. flow)
Maybe the author feels left out for not knowing typescript, but honestly, it's kinda becoming a requirement in the industry these days. I might understand being reluctant to learn C++ and its toolchain for a one-off fix in some Node-GYP thing, but being able to understand typescript is something that one could reasonably expect a senior level frontend person to be able to handle nowadays.