3 ms·

But the point is it creates fragmentation.

ryandvm 6y ago
No, JavaScript being the kind of language that requires 3rd parties to implement what should be core features is what creates fragmentation. There was similar fragmentation with JavaScript's async patterns. Callbacks, promises, async/await also resulted in fragmentation as you had different projects supporting different patterns as 3rd parties introduced new capabilities (that eventually graduated into fully-fledged language features). Hopefully the best of what TypeScript provides will make its way into the ECMAScript spec eventually...
- danShumway 6y ago
  Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto I think about the fragmentation that shows up in the form of multiple frameworks and patterns as a necessary part of that. It's not something that I want to fix. So to draw a line and say, "extending core Javascript features is fine, but compiling into Javascript isn't" -- I just don't get that. Typescript is a testing ground not just for typed programming in general, but also for features like decorators and meta-programming features. It's good to have a diversity in what people are building and using, that's how we get real world data on what works.
- oaiey 6y ago
  You forgot observables :)
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.

No, JavaScript being the kind of language that requires 3rd parties to implement what should be core features is what creates fragmentation. There was similar fragmentation with JavaScript's async patterns. Callbacks, promises, async/await also resulted in fragmentation as you had different projects supporting different patterns as 3rd parties introduced new capabilities (that eventually graduated into fully-fledged language features). Hopefully the best of what TypeScript provides will make its way into the ECMAScript spec eventually...

danShumway 6y ago
Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto https://github.com/extensibleweb/manifesto I think about the fragmentation that shows up in the form of multiple frameworks and patterns as a necessary part of that. It's not something that I want to fix. So to draw a line and say, "extending core Javascript features is fine, but compiling into Javascript isn't" -- I just don't get that. Typescript is a testing ground not just for typed programming in general, but also for features like decorators and meta-programming features. It's good to have a diversity in what people are building and using, that's how we get real world data on what works.
oaiey 6y ago
You forgot observables :)

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.