[azangru]

But Typescript is a language on its own. It claims to be a superset of JavaScript, but includes JS features that aren’t even certain to end up in JS (decorators). And their import system... Whereas Flow is proper JS. It’s just so... nice!

[sbjs]

That's not true. TypeScript spec is just the latest JavaScript spec. Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. And TypeScript uses the ECMAScript module system. Whatever other features you think TypeScript has that aren't "proper JS" probably are either already JS, or are late-stage TC39 proposals.

[azangru]

> And TypeScript uses the ECMAScript module system.

Erm, I was thinking of a discussion like the one over here:

https://github.com/Microsoft/TypeScript-React-Starter/issues...

Q: `import React from "react";` breaks in Typescript

A: have you tried `import * as React from 'react';`

Me: Golly!

> Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators.

Oh, didn’t know about the flag; I thought it's already a standard language feature now, what with all the Angular apps relying on it. As for decorators being a TC39 proposal, I am aware of that, but they have remained a proposal for quite a long time now, haven’t they (about 4 years now?), and I remember babel renaming the transformer for decorators to legacy-decorators-something, saying that the very semantics of decorators in JS is still debatable (some thought of them simply in terms of functions accepting a function and returning another function; some in more angular sense of injecting some properties into methods). I hope I am not completely misrepresenting the rationale here.

[jacobr]

Pretty sure `import * as React from 'react';` is the correct EcmaScript syntax because React does not expose an ES module compatible `default` export. You're just used to it working anyway thanks to babel accepting CommonJS modules, but TypeScript is the one that actually follows the standard here.

[orf]

> A: have you tried `import * as React from 'react';`

> Me: Golly!

You're fundamentally misrepresenting that whole issue, and if you'd read just two or three comments down you'd see that there is a better fix, and part of the problem is a behaviour that's not even related to the ECMAScript standard.

[azangru]

Yes, I missed that, thank you for the rebuke.

[sbjs]

Ah right, the `import * as` problem. That was fixed with --allowSyntheticDefaultImports. According to the docs:

> Allow default imports from modules with no default export. This does not affect code emit, just typechecking.

https://www.typescriptlang.org/docs/handbook/compiler-option...

And I think you're right about decorators. They are an iffy concept in the context of JS semantics, and I personally avoid using them and try to avoid libraries that use them. That's probably why TS has them disabled by default and calls them "experimental". I like the concept of decorators in and of themselves, but they don't fit cleanly into the JS world, and I am looking forward to seeing how the JS/TS world innovates alternative "cleaner" solutions that fit better into the existing model!

[xanderjanz]

We have high order functions in JS. Which are similar to decorators.

[sbjs]

Similar, but harder to use safely and correctly in class methods using the new class syntax. There's more surface area for typos and other mismatch errors since you have to type the method names twice. See: https://mobx.js.org/best/decorators.html

[mediumdeviation]

Enums are not JavaScript, and I've never heard of an Enum stage X proposal.

[sbjs]

Oh, you're right!

http://www.typescriptlang.org/play/#src=enum%20Direction%20%...

And yeah this could be valid JavaScript too, having nothing to do with types, but it's not in JS, only TS.

That said, it is a very cool and clever way to set k=v and v=k in an object at the same time!

[RyanCavanaugh]

What definition of "superset" are you using?