6 ms·

For me, I like how it's designed to complement the language, not to replace it with a (very closely related) cousin. The conversion from JS-with-flow-types to

by muglug 10y ago

For me, I like how it's designed to complement the language, not to replace it with a (very closely related) cousin. The conversion from JS-with-flow-types to plain JS is just a matter of stripping out that type information, which I feel is conceptually simpler than TypeScript's approach.

msoad 10y ago
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
- smt88 10y ago
  > Flow is a different language than JS How so? Isn't JS-with-Flow just JS with specially formatted comments?
  - abritinthebay 10y ago
    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
    - jankassens 10y ago
      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.
      - abritinthebay 10y ago
        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.
- 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
shouldbworking 10y ago
To me it doesn't matter that typescript replaces js because TS is forwards and backwards compatible, something nobody else is really attempting. typescript (unlike Babel) is designed to output JavaScript that's as close as possible to what a human would write. If you get tired of Typescript you just transpile your code down to js one last time and forget about it. Look at the output of Babel vs Typescript and you'll see what I mean about human friendliness. IMO the best tools are the ones easy to get rid of and typescript definitely scratches that itch.
- dotancohen 10y ago
  > the best tools are the ones easy to get rid of Thank you, you've just summed up the entire proprietary vs FOSS debate _and_ the bus factor in a way that anybody could understand! I am definitely going to be repeating this wisdom!
- woah 10y ago
  Babel actually started with the express goal of outputting human-readable Javascript. It obviously hasn't stayed that way. IMO, Typescript hasn't stayed that way either. Trying to shoot for a compilation target that is useable as source code is pretty foolish. The nice thing about Flow is that the compilation step is nothing more than stripping out the typing syntax. It is ACTUALLY easy to get rid of. I will say that the tooling is way better in Typescript.
johnfn 10y ago
This is a common misconception about Typescript. Typescript has no additional features over (ES6+) JavaScript that are not part of the type system.
- Chyzwar 10y ago
  Decorators, interfaces, namespaces, readonly, private and there is probably more corner cases. Typescript compile to JavaScript and it smell like lock-in. In flow you can simply strip type annotations, and you are back to pure JS.
  - johnfn 10y ago
    Decorators are ES7 stage 1 and can be found in Babel. (They were actually demanded by the angular team.) Interfaces are types. Namespaces are namespaced types. Readonly and private are type modifiers. You strip out all of those and you have a working JavaScript program. I don't understand why this myth persists.
    - bakkoting 10y ago
      Decorators, and class fields, are pre-stage-4 ES proposals. That means they are not part of JavaScript. Moreover, what ends up eventually landing, especially in the case of decorators, is unlikely to work quite the same as what TypeScript implements. So "Typescript has no additional features over (ES6+) JavaScript that are not part of the type system." is just false. (Babel has plugins for all kinds of things that aren't part of JavaScript. The team is working on expressing more clearly which plugins are for experimental features and which are settled.)
      - johnfn 10y ago
        You're moving the goalposts. GP was concerned about MS nefariously introducing vendor lock-in by implementing a bunch of their own proprietary features. I've demonstrated pretty clearly that 1. It's not MS's implementation - it's an implementation of an ES proposal. 2. For the one example you could find, MS didn't even want to do it - it was requested by Google for Angular and done as essentially a compromise. If you browse the TS repository, you can find issue after issue of the TS team refusing to add features that aren't part of the ES standard. I think this shows fairly definitively that this is not a case of MS trying to lock you in to their product.

by muglug 10y ago

msoad 10y ago

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

smt88 10y ago
> Flow is a different language than JS How so? Isn't JS-with-Flow just JS with specially formatted comments?
- abritinthebay 10y ago
  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
  - jankassens 10y ago
    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.
    - abritinthebay 10y ago
      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.
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

shouldbworking 10y ago

To me it doesn't matter that typescript replaces js because TS is forwards and backwards compatible, something nobody else is really attempting. typescript (unlike Babel) is designed to output JavaScript that's as close as possible to what a human would write. If you get tired of Typescript you just transpile your code down to js one last time and forget about it. Look at the output of Babel vs Typescript and you'll see what I mean about human friendliness. IMO the best tools are the ones easy to get rid of and typescript definitely scratches that itch.

dotancohen 10y ago
> the best tools are the ones easy to get rid of Thank you, you've just summed up the entire proprietary vs FOSS debate _and_ the bus factor in a way that anybody could understand! I am definitely going to be repeating this wisdom!
woah 10y ago
Babel actually started with the express goal of outputting human-readable Javascript. It obviously hasn't stayed that way. IMO, Typescript hasn't stayed that way either. Trying to shoot for a compilation target that is useable as source code is pretty foolish. The nice thing about Flow is that the compilation step is nothing more than stripping out the typing syntax. It is ACTUALLY easy to get rid of. I will say that the tooling is way better in Typescript.

johnfn 10y ago

This is a common misconception about Typescript. Typescript has no additional features over (ES6+) JavaScript that are not part of the type system.

Chyzwar 10y ago
Decorators, interfaces, namespaces, readonly, private and there is probably more corner cases. Typescript compile to JavaScript and it smell like lock-in. In flow you can simply strip type annotations, and you are back to pure JS.
- johnfn 10y ago
  Decorators are ES7 stage 1 and can be found in Babel. (They were actually demanded by the angular team.) Interfaces are types. Namespaces are namespaced types. Readonly and private are type modifiers. You strip out all of those and you have a working JavaScript program. I don't understand why this myth persists.
  - bakkoting 10y ago
    Decorators, and class fields, are pre-stage-4 ES proposals. That means they are not part of JavaScript. Moreover, what ends up eventually landing, especially in the case of decorators, is unlikely to work quite the same as what TypeScript implements. So "Typescript has no additional features over (ES6+) JavaScript that are not part of the type system." is just false. (Babel has plugins for all kinds of things that aren't part of JavaScript. The team is working on expressing more clearly which plugins are for experimental features and which are settled.)
    - johnfn 10y ago
      You're moving the goalposts. GP was concerned about MS nefariously introducing vendor lock-in by implementing a bunch of their own proprietary features. I've demonstrated pretty clearly that 1. It's not MS's implementation - it's an implementation of an ES proposal. 2. For the one example you could find, MS didn't even want to do it - it was requested by Google for Angular and done as essentially a compromise. If you browse the TS repository, you can find issue after issue of the TS team refusing to add features that aren't part of the ES standard. I think this shows fairly definitively that this is not a case of MS trying to lock you in to their product.