4 ms·

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 chang

by ng12 10y ago

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.

Touche 10y ago
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.
- ng12 10y ago
  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".
spion 10y ago
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.
- ng12 10y ago
  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.
  - WorldMaker 10y ago
    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.
    - ng12 10y ago
      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.
      - WorldMaker 10y ago
        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.

by ng12 10y ago

Touche 10y ago

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.

ng12 10y ago
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".

spion 10y ago

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.

ng12 10y ago
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.
- WorldMaker 10y ago
  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.
  - ng12 10y ago
    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.
    - WorldMaker 10y ago
      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.