5 ms·

The author admits to not using Typescript and not knowing how it works but is quick to point out that it’s polluting the JavaScript community? He does state th

by gvkhna 6y ago

The author admits to not using Typescript and not knowing how it works but is quick to point out that it’s polluting the JavaScript community? He does state that typescript is a subset of JavaScript and this compiles to JS so I largely don’t see the problem. TS is making complex projects in JS more tenable and I believe we should encourage TS. A separate repo for TS doesn’t make sense, Microsoft owns npm now by extension of github and is doing fantastic work supporting TS and by extension JS. My hope is the opposite, at some point TS is the gold standard for a package, it is self documenting and again the types can be stripped out (and usually are for distribution).

deleted 6y ago
[deleted]
digitaltrees 6y ago
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.
timdaub 6y ago
To me whether or not using JS or TS as the "gold standard" for a package is insignificant. I've argued that JavaScript is not the same as TypeScript. It may be transpiled but it's not the same. Hence, being kinda pedantic in my rhetoric while e.g. a popularity increase in TypeScript may, strengthen e.g. the web ecosystem because more programs have less bugs because devs use types, it doesn't directly strengthen or benefit the JavaScript language (which is the one without types). For now, what I can see is that my argument (e.g. in the comments of this thread) creates fragmentation and controversy.

by gvkhna 6y ago

deleted 6y ago

[deleted]

digitaltrees 6y ago

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.

timdaub 6y ago

To me whether or not using JS or TS as the "gold standard" for a package is insignificant. I've argued that JavaScript is not the same as TypeScript. It may be transpiled but it's not the same. Hence, being kinda pedantic in my rhetoric while e.g. a popularity increase in TypeScript may, strengthen e.g. the web ecosystem because more programs have less bugs because devs use types, it doesn't directly strengthen or benefit the JavaScript language (which is the one without types). For now, what I can see is that my argument (e.g. in the comments of this thread) creates fragmentation and controversy.