TypeScript 2.7 and 2.8 features

[niieani]

We need to update the readme to add the latest features from TS 2.7 and 2.8.

Help appreciated!

[michaeljota]

I am on it. Now that I had you here, I think there should be a section of the document for a what-is comparison. I mean, Typescript is a complete language, a strict super set of JavaScript, and does not need anything else aside the Typescript compiler. Other things too, but, that's consistent. And Flow is only a static type checker, it needs something to eliminate the typing of the code, this is probably Babel works. There are a few advantages, for one side, or other, but I do have to say that with Typescript you only need it, and with Flow you would need, Babel and all that.

[niieani]

Thanks!

As for your comment on what-is, I would say a better comparison would be of steps necessary to run TS vs Flow. They're both supersets of JavaScript, and they're both their own languages. It's just different marketing, plus TS requires you to change the file extension, and Flow doesn't.

I think more importantly, the valid difference is that:

TypeScript has both

• a typechecker
• its own emitter/compiler

While Flow only does the first, and needs either babel, flow-stip-types (or something else) to do the actual emitting.

But you can also setup TypeScript as a typechecker only, and similarly use babel for emitting. So in that respect, they're no different.

[michaeljota]

But Flow is not a language, it have its own syntax, but it's not a language. Typescript have language features, like Enums, Interfaces, to name a few.

You have a point regarding that you can compile a Typescript file using Babel 7, but I don't think I would really check for type errors, it just would remove the type code.

And, you can use the power of Typescript in plain Javascript, with a magic comment // @ts-check

[michaeljota]

I made the PR. I hope you like it. If you fell something is missing, I'll add it. Thanks you.

[michaeljota]

Update: I ask for a way to implement a $Diff like in Typescript using Conditional Typing:

class A {
  a: string;
  b: string;
}

class B {
  a: string;
  c: string;
}

type C = Pick<A, Exclude<keyof A, keyof B>>;

This work, but is not exact the behavior, as in Flow, this would throw because B have properties that A does not have. Here, the extra properties are just ignored.

[niieani]

Thanks @michaeljota. I'll have a look at it this week!

[chrisgervang]

ReturnType, and other predefined conditional types were added microsoft/TypeScript#21847

They also added a feature for folks to make their own conditions types: microsoft/TypeScript#21496

:)

[niieani]

@michaeljota

But Flow is not a language, it have its own syntax, but it's not a language. Typescript have language features, like Enums, Interfaces, to name a few.

To my knowledge, the only two places where TypeScript adds a feature that is not just a type annotation are Enums and class members declared in the constructor. But that's essentially like having a special babel plugin for these two.
Every other TypeScript-specific syntax has to do with type checking only.

With just these two differences, I don't think its enough to segment TypeScript and Flowtype as different "things" (whether we call both a new language, or a new syntax for an old language).

The point of this repo is to show both differences and similarities. While I think it's important to point out these 2 special emit TypeScript features, overall, both projects are essentially: JavaScript with a syntactic extension for typechecking. One more noteworthy difference is that TypeScript includes its own emitter/transpiler, while Flow requires an external one (Babel or flow-strip-types).

You have a point regarding that you can compile a Typescript file using Babel 7, but I don't think I would really check for type errors, it just would remove the type code.

Sure, just as Babel doesn't check type errors when compiling Flowtype, it wouldn't check for type errors when compiling TypeScript.

And, you can use the power of Typescript in plain Javascript, with a magic comment // @ts-check

Indeed! This would be great to mention in the readme. The @ts-check mode is something that makes use of TypeScript's type-checking only, making it the closest to Flowtype's comment annotation syntax.

[michaeljota]

To my knowledge, the only two places where TypeScript adds a feature that is not just a type annotation are Enums and class members declared in the constructor. But that's essentially like having a special babel plugin for these two.
Every other TypeScript-specific syntax has to do with type checking only.

This is true in part, because Typescript have aligned itself with a more stricter super set of JavaScript plan, but they did include in the past several features that were not available in plain JavaScript, like modules, and private members.

With just these two differences, I don't think its enough to segment TypeScript and Flowtype as different "things" (whether we call both a new language, or a new syntax for an old language).

I think is about semantic here. Flow only purpose is to add type checking to JavaScript, you can use plain JavaScript, and remove the type info with flow-remove-types, and if you want to use additional properties, then you would need Babel and configure it will all the plugins you would need to. Typescript required anything, but itself.

Both of them have its advantage, with Flow and Babel you can use ES proposal in low stages, and with Typescript you would have to wait until the compiler adds them, probably until Stage 3. Typescript is simpler to setup, but still powerful.

Anyway, I'm writing this in a blog Typescript vs Flow.

[niieani]

Yeah, I agree, it's a discussion about semantics. All in all, I think it's important to understand the difference, but at the same time see how TypeScript is two tools in one (typechecker + transpiler).

with Flow and Babel you can use ES proposal in low stages

This is not actually correct, since Flow still needs to support parsing and typechecking for these proposals. The situation is really the same as with TypeScript, and in fact, some low stage proposals (like decorators) have better support in TypeScript than with Flow, which doesn't do any type checking for decorators.

[michaeljota]

I see. As I said, I haven't use Flow that much, so my knowledge about it is quite limited. I do have a few tears years with Typescript. 😌

[bfricka]

While I don't think it's such a big deal, TypeScript does allow you to forego Babel as it compiles language features. You can even include the helper library tslib separately using "importHelpers": true in tsconfig.json for things like async/await, object spread, etc.

Personally, this isn't a large consideration for me, but it is a distinction that differentiates TypeScript as more of a compiler than simply a type checker. Additionally, you can use TypeScript as a compiler only and if you want to avoid the cost of type-checking in certain scenarios. For example, it's common in Webpack projects to use the TS Loader with transpileOnly: true and then type check in a separate thread with the Fork TS Checker Plugin.

[niieani]

Absolutely @bfricka. I'd be happy to accept PRs adding & describing these similarities & differences.