Flow is a different language than JS. Keeping the .js extension doesn't make it a "close to JS" language. TypeScript and Flow are both supersets of JS
How so? Isn't JS-with-Flow just JS with specially formatted comments?
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
Which is sadly important - for something so optional.
Sidenote that Flow does allow specifying types through comments but this is a bit of a second-class feature.
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.
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;
}
function foo(x /*: string */, y /*: number */) /*: boolean */ {
return x.length * y === 5;
}
> 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'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.
~: 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 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.
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.
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.
Read the rest of this thread, that is the point at hand. I'd generally suggest doing that before jumping in.
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
This is literally exactly the same amount of true for TypeScript as it is for Flow
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.