5 ms·

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. Typescr

by ng12 10y ago

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.

Touche 10y ago
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.
- 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.
RyanCavanaugh 10y ago
"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
- STRML 10y ago
  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.
  - WorldMaker 10y ago
    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.)
- ng12 10y ago
  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.
- woah 10y ago
  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.
deleted 10y ago
[deleted]

by ng12 10y ago

Touche 10y ago

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.

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.

RyanCavanaugh 10y ago

"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

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

deleted 10y ago

[deleted]