> Flow is a different language than JS

How so? Isn't JS-with-Flow just JS with specially formatted comments?

That's one option (my favorite and the simplest to use).

But the "default" is annotated JS which is not dissimilar to how TS operates.

I prefer Flow's syntax and if it wasn't for the annoying "you have to run a server to check code" thing... I'd use it a lot more

You can use `flow check`, but the server has the benefit of giving almost instant responses even on large code bases by only revalidating a subset of the project.

Yeah, there are ways to configure it to be better but it's just not... "nice" out of the box.

Which is sadly important - for something so optional.

But Flow is actually a superset of JS -- without the types your code is perfectly valid JS, which is what actually happens via a simple Babel transform. Typescript is both a transpiler and a language, it's much further from pure JS. The actual advantage of this is you can drop Flow in any Babel project. With Typescript you need additional tooling.

They are both supersets. If you remove the non-JS features you have valid JS. But of course without removing it you have invalid JS. That's why both require tools.

Sidenote that Flow does allow specifying types through comments but this is a bit of a second-class feature.

Sorry, let me try to be more clear -- because this is a very real distinction which does have practical implications.

You can run Flow on ES code without changing it. If you have type annotations it will use them to help find errors, and you can use a simple tool to strip them out. The key thing here is that the "stripped" code is EXACTLY your source minus the type annotations. Typescript does not operate like this -- you cannot make assumptions about what the code looks like post-tsc. This is very important if you have some other tools, like Babel plugins, which operate on your code. You're likely to run into trouble if you want to use syntax Typescript doesn't understand or if a tool is doing some sort of code analysis.

Typescript is a language but Flow is much closer to a linter.

Sorry, Flow is a different language. The fact that it reuses a JS extension doesn't matter. Adding type annotations means that the language is no longer ES.next. The only reason Babel and the surrounding tooling understands it is because they, too, have been extended by Facebook to support said type annotations.

Try another ES.next tool, and it wont work. There are no type annotations in any ES spec.

Its the exact same thing, only MS is a bit more straight-forward about it (that its a different language). They are also siloed a bit more, perhaps - they could send a PR over to Babylon to add basic TS parsing support. But then they'd have to maintain that in sync with the original compiler.

If MS did what FB does, everyone would blame them for "embrace, extend, extinguish", pushing their own typed JS dialect by taking advantage of their influence in the JavaScript community, and falsely presenting it as "more JS" than the competing typed dialect.

I'm assuming FB have the best intentions, and I think they did it this way because they want to work with the existing open source community and standards bodies (avoid being siloed). But thats the only difference I can think of.

Ah, and yes, you can write all your types in comments. Thats a fair point. But it seems like they picked the most unergonomic way of doing this. The original extension supported this syntax

  /*: (x: string, y: number): boolean */
  function foo(x, y) {
    return x.length * y === 5;
  }

But thats gone, and current flowtype only supports this:

  function foo(x /*: string */, y /*: number */) /*: boolean */ {
    return x.length * y === 5;
  }

which is terrible to both write and read.

I never said flow wasn't a different language or that it conformed to any ES spec.

> Its the exact same thing, only MS is a bit more straight-forward about it

This is what people are not understanding. Flow lints your code, then removes the types, leaving you with valid ES6 that is EXACTLY your source code without the types. Typescript is fundamentally different -- it transpiles your code and you cannot make assumptions about what that code looks like. They are not the exact same thing by any metric.

Typescript lints your code, then removes the types, leaving you with valid ES2015 that is EXACTLY your source code without types when you target ES2015 and stick to writing ES2015.

Typescript's transpilations are primarily to downlevel "future" ES features to previous ES versions (just like Babel). In my experience you absolutely can make assumptions about what the code looks like, and I have never been surprised by Typescript's output.

Typescript and Flow are a lot the same. Typescript has a few more "Babel features" built in.

This is demonstrably false. Typescript makes no guarantees about what the output looks like. Take this incredibly simple example:

   ~: cat test.ts
   class Foo {
      foo = () => console.log('Foo!')
   }
   ~: tsc --target es6 test.ts && cat test.js
   class Foo {
      constructor() {
         this.foo = () => console.log('Foo!');
      }
   }

The code is functionally the same but not identical, which like I said earlier can be an issue if you're using other tools which analyze/modify your code. I prefer Typescript over Flow for other reasons but the amount of misinformation in this thread is astounding.

Flow understands this code perfectly well too.

https://tryflow.org/?code=Y2xhc3MgRm9vIHsKICBmb28gPSAoKSA9Pi...

You get no errors.

Additionally, TypeScript's stated design goal is to not deviate from current or future EcmaScript [1]

You want more control over exactly what gets transpiled i.e. "I don't want to use ES.next, only ES6". Thats a valid point, but really far from your original assessment that there is a fundamental difference between the languages.

[1]: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... - goal 6

Your class is not syntactically valid ES2015. Typescript is allowing a shorthand that ES2015 doesn't allow and rewrites it to proper ES2015. It's a tiny babel plugin. Maybe a stricter output target should provide a syntax warning here.

The source conversion here, based on the implications of the shorthand, shouldn't be a surprising output and looks like perfectly readable, idiomatic JS to me.

Can you turn of those transpilations though? Readable code isn't the problem, equivalence is. Flow will never rewrite anything, which is what I've been saying.

Many of the transpilations you can turn off. The targets system turns off/on many transpilations as a suite. There are flags for several others such as `--noEmitHelpers`, `--preserveConstEnums`, `--jsx Preserve`.

If you have a reason to disallow and/or preserve something that TS does not already support, I would think the Typescript team would be interested in hearing about it.

But the argument I'm making is it's disingenuous to say that Flow and Typescript are both equally "not Javascript". Flow is _strictly_ additive to whatever else your toolchain is. Typescript is a different language.

I never said that Flow and Typescript are "equally" not JavaScript. I think you are getting your arguments crossed here.

Though I will state that both are not JavaScript, even if they are "unequally" not JS (for whatever that distinction means to you, though I think it is a moot point). Flow when used purely as comments is JS, sure, but the type annotation syntax is not JS as defined by any ES standard (except maybe ES4) nor any JS accepted by browsers (definitely not ES4). "Strictly additive" isn't a distinction that matters to what constitutes a language, if we want to be pedantic.

Finally, I would suggest you refrain from the word "disingenuous". Yes, my opinions differ from your own, but you cannot speak to the candor of my opinions here. I am hoping you did not intend an ad hominem attack, but I don't think a lot of people realize how much "disingenuous" is an ad hominem attack.

> I never said that Flow and Typescript are "equally" not JavaScript. I think you are getting your arguments crossed here.

Read the rest of this thread, that is the point at hand. I'd generally suggest doing that before jumping in.

I commented on a specific point you were making. Whether or not I read the rest of the thread is irrelevant to the discussion at hand.

So it's just an irrelevant interjection then? Your not wrong, I'm not wrong, we're just having two separate conversations.

You're describing a property of their compilers as evidence that one is a superset and one is not. That TS transforms your code doesn't make it not a superset. It would not be a superset if it didn't support some JS feature. If it didn't support extends or something.

I'm not saying Typescript isn't a superset of JavaScript, I'm saying Flow is more direct superset in a way that's important. I'm more trying to clarify people who are saying Flow and TS are both supersets and therefore directly comparable. Specifically, the root poster's contention was that they're both supersets and therefore​ both "not JS".

"without the types your code is perfectly valid JS, which is what actually happens via a simple Babel transform"

This is literally exactly the same amount of true for TypeScript as it is for Flow

They're different. Flow is not a "superset" of JS in that it introduces new features, it only introduces new types of annotations. Remove all the annotations (literally delete them), and you have valid ES6.

Typescript has its own class system, public/private/protected, and its own compiler. This was a big negative while ES6 was still brand new and the TS compiler was catching up, but now it's pretty much a wash between the two.

A year ago, I would have said Flow, no question. Today, TS has really caught up and the tooling is better, no doubt. It depends on how complex your types are - Flow can express types TS can't, but TS has an incredible ecosystem and far fewer bugs. In the end, it's all about reducing bugs in your own application, and TS seems to do that better in the end despite its limitations.

The class system was already an EcmaScript proposal at the time Typescript adopted it, and what Typescript launched with was directly based on the ES proposal at the time. The proposal shifted a bit before it was finalized and TS did the necessary catch-up work to the final accepted specification. It hasn't added anything whole cloth other than types that wasn't in some stage or another an ES proposal. (From that perspective TS has always been Flow + a few curated Babel plugins.)

Not true. Typescript does all kinds of transforms. Flow does nothing except catch type errors, and then it is simply stripped out. Nothing else in the code is touched at all.

See my comment above, but this is not true. The output of the type stripping is exactly your code without types. This is not true for Typescript.