4 ms·

I think comparing typescript to coffeescript is a very amateur call. Coffeescript specifically decided to throw out ECMA script. Typescript embraces it. Ther

I think comparing typescript to coffeescript is a very amateur call. Coffeescript specifically decided to throw out ECMA script. Typescript embraces it. There was SO SO SO much waiting around the ".?" operator in TS because they specifically did NOT want to do what coffeescript did (make their own, and then get hosed when the official spec came out and they were different from their own implimentation). The -only- difference between TS and JS is the type annotations. It should be perfectly readable JS aside from that. Objective-C can actually compile C. Objective-C is a -superset- of C. So again, the argument is misguided. All the typescript webpack plugin does is strip out typescript stuff. And that leaves you with the underlying JS. Typescript projects should be pushed up to NPM with their transpiled modules. I believe any small bug that the author of this article was hoping to fix in subprojects should have been caught by the typing system. You should see about 25% less bugs in TS code vs JS (number pulled semi-out of my ass, pulled from some strong blog with strong opinions against TS). I believe, if anything, that TS's impact on the JS ecosystem is incredibly important for the long term survivability and reliability of it. As our sub projects get larger and more complicated, having the compiler save our collective butts is huge.

oaiey 6y ago
To be fair there is TypeScript code which is not idiomatic to JS. I at least remember the early namespace system. Not so sure about 2020 TypeScript. But I agree with everything else you wrote.
- WorldMaker 6y ago
  2020 Typescript has very few non-idiomatic JS constructs left, most of which are left only for compatibility reasons with really old TS code, have deprecation markers or strict flag errors around their usage, and generally are frowned upon, with one odd exception that proves the rule. Almost all of them come from the early days of module development as ES2015 and ES2015 modules were finalized. Most of them resemble idiomatic JS of their time. There's an old import and export syntax that idiomatically looks and acts more like CommonJS (aka most older npm packages). That's been deprecated since 1.x and I believe an error or warning since 2.x. The "namespace" thing you are probably recalling is about the only surviving piece of that legacy, as the exception that proves the rule. It got renamed to "module" to at least sound more JS than C#, and while the syntax is still not entirely idiomatic, the concept that it has always wrapped and been mere syntactic sugar for is a classic (thankfully on life support more than not) pattern: the IIFE [Immediately Invoked Function Expression] module pattern.
  - oaiey 6y ago
    Thanks. Yeah, that is also my limited insight.
genuine_smiles 6y ago
> The -only- difference between TS and JS is the type annotations. It should be perfectly readable JS aside from that. TypeScript has a few differences: Automatic class properties from arguments: class Foo { constructor( public bar: string, ) {} } Enums, and probably other stuff I've forgotten. I think they're avoiding adding any other differences though.
- timdaub 6y ago
  I find this argument weird. JS doesn't have Public Class fields yet [1] (stage 3), hence any TS or JS code making use of such concept will differ. Similarly, as reliance of types in JS is not guaranteed, as it may in TS, will produce code with different assumptions too. So while you may "easily" go from (1) JS => TS, it may be much harder going from (2) TS => JS, as in (1) you're preserving all information and in (2) you're losing information. My point being, TS !== JS. - [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- virtue3 6y ago
  I mean, enums literally get compiled into an object at runtime so aside from the definition it's basically the same :/ They're definition avoiding anything different now: see goal 6: https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...
timdaub 6y ago
You're making a fine argument, but you assume things freeze in time. Whether or not TS will stick to ECMA script in the future is speculation. A similar argument to yours could be made where we speculated that JS introduces a typing system in the future and hence creates an incompatibility (to .e.g. TS), hence TS is bad. But I've specifically not tried to speculate in the post. I value that the two languages are very similar and that TS respects ECMA script. However, my argument was (whether you think it was misguided by that silly Objective-C example or not) that TS and JS are different by equality and identity (current and potentially for the future), which is why they belong in different package managers.
- virtue3 6y ago
  Except its directly trended towards being like JS. It was slightly divergent at some point. (see other commends under my original). Your reasoning is unsound. I'm sorry. https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... Please see goal number 6. Typescript is an opensource language (probably in mostly control of MS. but they are a -very- different company from even 10 years ago). I can tell you from the last few years that they are taking it very very seriously. Now that ES is actually moving again, no one wants a repeat of coffeescript. Your argument is basically also saying that JSX/React are bad as well and should not be in npm either. I don't think any npm package owes it to anyone to be in any language. They are just under the contract of producing javascript that is runnable under the node versions they've specified (and even then, not even, as there are plenty of browser-only packages). There are plenty of npm modules that have some sort of compilation from C or some such. (anything with node-gyp). Not as common as in ruby land but still happens.

oaiey 6y ago

To be fair there is TypeScript code which is not idiomatic to JS. I at least remember the early namespace system. Not so sure about 2020 TypeScript. But I agree with everything else you wrote.

WorldMaker 6y ago
2020 Typescript has very few non-idiomatic JS constructs left, most of which are left only for compatibility reasons with really old TS code, have deprecation markers or strict flag errors around their usage, and generally are frowned upon, with one odd exception that proves the rule. Almost all of them come from the early days of module development as ES2015 and ES2015 modules were finalized. Most of them resemble idiomatic JS of their time. There's an old import and export syntax that idiomatically looks and acts more like CommonJS (aka most older npm packages). That's been deprecated since 1.x and I believe an error or warning since 2.x. The "namespace" thing you are probably recalling is about the only surviving piece of that legacy, as the exception that proves the rule. It got renamed to "module" to at least sound more JS than C#, and while the syntax is still not entirely idiomatic, the concept that it has always wrapped and been mere syntactic sugar for is a classic (thankfully on life support more than not) pattern: the IIFE [Immediately Invoked Function Expression] module pattern.
- oaiey 6y ago
  Thanks. Yeah, that is also my limited insight.

genuine_smiles 6y ago

> The -only- difference between TS and JS is the type annotations. It should be perfectly readable JS aside from that. TypeScript has a few differences: Automatic class properties from arguments: class Foo { constructor( public bar: string, ) {} } Enums, and probably other stuff I've forgotten. I think they're avoiding adding any other differences though.

timdaub 6y ago
I find this argument weird. JS doesn't have Public Class fields yet [1] (stage 3), hence any TS or JS code making use of such concept will differ. Similarly, as reliance of types in JS is not guaranteed, as it may in TS, will produce code with different assumptions too. So while you may "easily" go from (1) JS => TS, it may be much harder going from (2) TS => JS, as in (1) you're preserving all information and in (2) you're losing information. My point being, TS !== JS. - [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
virtue3 6y ago
I mean, enums literally get compiled into an object at runtime so aside from the definition it's basically the same :/ They're definition avoiding anything different now: see goal 6: https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...

timdaub 6y ago

You're making a fine argument, but you assume things freeze in time. Whether or not TS will stick to ECMA script in the future is speculation. A similar argument to yours could be made where we speculated that JS introduces a typing system in the future and hence creates an incompatibility (to .e.g. TS), hence TS is bad. But I've specifically not tried to speculate in the post. I value that the two languages are very similar and that TS respects ECMA script. However, my argument was (whether you think it was misguided by that silly Objective-C example or not) that TS and JS are different by equality and identity (current and potentially for the future), which is why they belong in different package managers.

virtue3 6y ago
Except its directly trended towards being like JS. It was slightly divergent at some point. (see other commends under my original). Your reasoning is unsound. I'm sorry. https://github.com/microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... Please see goal number 6. Typescript is an opensource language (probably in mostly control of MS. but they are a -very- different company from even 10 years ago). I can tell you from the last few years that they are taking it very very seriously. Now that ES is actually moving again, no one wants a repeat of coffeescript. Your argument is basically also saying that JSX/React are bad as well and should not be in npm either. I don't think any npm package owes it to anyone to be in any language. They are just under the contract of producing javascript that is runnable under the node versions they've specified (and even then, not even, as there are plenty of browser-only packages). There are plenty of npm modules that have some sort of compilation from C or some such. (anything with node-gyp). Not as common as in ruby land but still happens.