6 ms·

The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax. This means I can just write JavaScript and add co

The biggest win that flow has - and for me puts it over typescript - is that it has comment decorator syntax. This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. It's inferred types are a much stronger system imo too - gets out of a developers way more. Typescript is great, but I really do prefer Flow in every metric.

huuu 10y ago
But programming with comments is bad practice. Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.
- sgift 10y ago
  That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.
  - huuu 10y ago
    IDEs can also mess with comments because they don't parse it as code. A simple extra linebreak added and your code breaks.
  - eksemplar 10y ago
    You're not wrong, but comments are bad practice because they allow you to write code you have to explain in a comment. In my opinion comment-less code works really well with SOLID because it forces your developers to code clean and decoupled. I've yet to be in a "oh this bit needs a comment" moments where the code couldn't be improved significantly to make it both better and more understandable.
    - underwater 10y ago
      Counterpoint for me: V8 source code. It's well written, and easy to follow when you know what you're looking at. But some comments would greatly improve the discoverability for new contributors.
  - pjmlp 10y ago
    Unfortunately code quality tends to be on the bottom of customer happy list. I also had the "pleasure" to work in a few projects where it wasn't even on the list, beyond a few powerpoint presentations.
  - seanwilson 10y ago
    > That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. An example might help but to me bad code is code that repeats itself which includes comments. To me, comments should only be used for high level explanations (e.g. architecture, algorithms, public API) and when the purpose of code is non obvious (e.g. weird bug workarounds, optimisations). The vast majority of comments can be removed by rolling their contents into better function and variable names.
- PDoyle 10y ago
  Not true when the comments are mechanically checked for correctness.
arvinsim 10y ago
Can you explain the difference between Flow's approach and plain JSDoc 3?
- girvo 10y ago
  Flow's type system is infinitely more powerful. It's proper static analysis. Tern, as an example, can only do so much.
  - deleted 10y ago
    [deleted]
- abritinthebay 10y ago
  JSDoc is verbose, not inline, not directly associated with the code and not very friendly to use, as well as having a large maintenance overhead..? I mean... that all applies to JSDoc/JavaDoc syntax before I compare it to Flow anyhow. Flow's comment system is inline - right next to the code you're writing. It's very clear exactly what it refers to and it's easy to use. Plus it's not TypeScript: it's JavaScript, just with comments. TypeScript is great, but it is what it is and that is not JavaScript (a superset, sure, but C++ is a superset of C, so what?)
Sacho 10y ago
> This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. Can't you do the same thing with TypeScript's typings?
- dtech 10y ago
  No. With flow you can do both: var x /*: string*/ = "" var x : string = "" With TS you can only do the latter. The first one has the advantage that it's legal Javascript, thus not requiring a compiler. Since typescript is set-up purely as a compiler anyway I'm not sure it would be a useful feature for them. A disadvantage could be that it's easier to make silent errors by making syntax errors in the comments. I don't how Flow would handle e.g. `var x /* number*/ = ""`
  - joshuacc 10y ago
    That's not entirely accurate. TypeScript 1.8 added the ability to use type information from JSDoc-style comments. For example: /** * @param {string} a * @param {number} b * @returns {string} */ function foo(a, b){ return a + b; } Is functionally identical to: function foo(a: string, b: number): string { return a + b; } See: https://github.com/Microsoft/TypeScript/issues/4790 https://github.com/Microsoft/TypeScript/issues/4790
    - Arnavion 10y ago
      Not equivalent - the TS compiler currently does not actually enforce the types in a JS file. See https://github.com/Microsoft/TypeScript/issues/4790#issuecomment-220807667 https://github.com/Microsoft/TypeScript/issues/4790#issuecom... The feature of parsing JSDoc comments is currently only used for providing completion info for JS editors and for consuming exported JS functions and variables in TS files.
      - joshuacc 10y ago
        Ah, you're right. Looks like I'd misunderstood the scope of that change.
smt88 10y ago
> no messing around in a different but similar language TypeScript would be a disaster if it subtly changed the semantics of JavaScript. It doesn't, though. It's a superset, so it's really not a "different but similar" language. It's the same language with more features, and the compiler is a great guide to using those features.
- tkubacki 10y ago
  what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.
  - smt88 10y ago
    > what if further JS will intersect with TS syntax A core value of TypeScript is to support the latest ES20xx standard. The TypeScript team pays attention to JavaScript proposals. In the unlikely event that JavaScript got a type system, it would almost definitely be either TypeScript or Flow. If it wasn't, or if ES standards overlapped with TS syntax, then TS would remove that syntax. Also, if you don't like the next version of TS, you can just use the old version to transpile your code and then stop using it. Switching to TS is an easily reversible decision, whether it's 1 day or 1 year later. > We need clean break with transpile step (eg. Dart) or annotations. You can already have this with Scala.js or any of the other languages that compile to JS. TypeScript is one option among many. The appeal of TypeScript is that it fixes some things about JavaScript rather than throwing the language away. That's useful because it allows teams to transition from one to the other gradually. Facebook had to do the same thing with PHP, so they created Hack.
    - tkubacki 10y ago
      "then TS would remove that syntax." So there is no hard promise of TS backward compatibility ? Sorry but whole TS looks like another EEE - MS will/can argue on some further JS changes for/against based on existing TS codebase. I hope I'm wrong here though.
DanRosenwasser 10y ago
Actually TypeScript powers a JS editing experience codenamed "Salsa" that uses JSDoc comments for types. You can try it out in VS Code where it should currently be enabled. Give that a shot if you're looking into that sort of workflow.
- abritinthebay 10y ago
  > uses JSDoc comments for types oh god... shivers... ;) No, that sounds neat but I loathe JSDoc/JavaDoc derived formats. Good idea for someone else though!

huuu 10y ago

But programming with comments is bad practice. Maybe in this case it doesn't matter very much but there are a lot of ways comments can get lost or messed up.

sgift 10y ago
That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. It probably has been changed in such a hurry that the comment was forgotten, which doesn't bode well for the code quality.
- huuu 10y ago
  IDEs can also mess with comments because they don't parse it as code. A simple extra linebreak added and your code breaks.
- eksemplar 10y ago
  You're not wrong, but comments are bad practice because they allow you to write code you have to explain in a comment. In my opinion comment-less code works really well with SOLID because it forces your developers to code clean and decoupled. I've yet to be in a "oh this bit needs a comment" moments where the code couldn't be improved significantly to make it both better and more understandable.
  - underwater 10y ago
    Counterpoint for me: V8 source code. It's well written, and easy to follow when you know what you're looking at. But some comments would greatly improve the discoverability for new contributors.
- pjmlp 10y ago
  Unfortunately code quality tends to be on the bottom of customer happy list. I also had the "pleasure" to work in a few projects where it wasn't even on the list, beyond a few powerpoint presentations.
- seanwilson 10y ago
  > That's a very common position, but my experience shows me if the comments are not in line with the code that is usually a very good hint that the code will be buggy. An example might help but to me bad code is code that repeats itself which includes comments. To me, comments should only be used for high level explanations (e.g. architecture, algorithms, public API) and when the purpose of code is non obvious (e.g. weird bug workarounds, optimisations). The vast majority of comments can be removed by rolling their contents into better function and variable names.
PDoyle 10y ago
Not true when the comments are mechanically checked for correctness.

arvinsim 10y ago

Can you explain the difference between Flow's approach and plain JSDoc 3?

girvo 10y ago
Flow's type system is infinitely more powerful. It's proper static analysis. Tern, as an example, can only do so much.
- deleted 10y ago
  [deleted]
abritinthebay 10y ago
JSDoc is verbose, not inline, not directly associated with the code and not very friendly to use, as well as having a large maintenance overhead..? I mean... that all applies to JSDoc/JavaDoc syntax before I compare it to Flow anyhow. Flow's comment system is inline - right next to the code you're writing. It's very clear exactly what it refers to and it's easy to use. Plus it's not TypeScript: it's JavaScript, just with comments. TypeScript is great, but it is what it is and that is not JavaScript (a superset, sure, but C++ is a superset of C, so what?)

Sacho 10y ago

> This means I can just write JavaScript and add comments for types. No transplier step, no messing around in a different but similar language, no additional complexity, just easy. Can't you do the same thing with TypeScript's typings?

dtech 10y ago
No. With flow you can do both: var x /*: string*/ = "" var x : string = "" With TS you can only do the latter. The first one has the advantage that it's legal Javascript, thus not requiring a compiler. Since typescript is set-up purely as a compiler anyway I'm not sure it would be a useful feature for them. A disadvantage could be that it's easier to make silent errors by making syntax errors in the comments. I don't how Flow would handle e.g. `var x /* number*/ = ""`
- joshuacc 10y ago
  That's not entirely accurate. TypeScript 1.8 added the ability to use type information from JSDoc-style comments. For example: /** * @param {string} a * @param {number} b * @returns {string} */ function foo(a, b){ return a + b; } Is functionally identical to: function foo(a: string, b: number): string { return a + b; } See: https://github.com/Microsoft/TypeScript/issues/4790 https://github.com/Microsoft/TypeScript/issues/4790
  - Arnavion 10y ago
    Not equivalent - the TS compiler currently does not actually enforce the types in a JS file. See https://github.com/Microsoft/TypeScript/issues/4790#issuecomment-220807667 https://github.com/Microsoft/TypeScript/issues/4790#issuecom... The feature of parsing JSDoc comments is currently only used for providing completion info for JS editors and for consuming exported JS functions and variables in TS files.
    - joshuacc 10y ago
      Ah, you're right. Looks like I'd misunderstood the scope of that change.

smt88 10y ago

> no messing around in a different but similar language TypeScript would be a disaster if it subtly changed the semantics of JavaScript. It doesn't, though. It's a superset, so it's really not a "different but similar" language. It's the same language with more features, and the compiler is a great guide to using those features.

tkubacki 10y ago
what if further JS will intersect with TS syntax ? IMO Typescript is "no go". We need clean break with transpile step (eg. Dart) or annotations.
- smt88 10y ago
  > what if further JS will intersect with TS syntax A core value of TypeScript is to support the latest ES20xx standard. The TypeScript team pays attention to JavaScript proposals. In the unlikely event that JavaScript got a type system, it would almost definitely be either TypeScript or Flow. If it wasn't, or if ES standards overlapped with TS syntax, then TS would remove that syntax. Also, if you don't like the next version of TS, you can just use the old version to transpile your code and then stop using it. Switching to TS is an easily reversible decision, whether it's 1 day or 1 year later. > We need clean break with transpile step (eg. Dart) or annotations. You can already have this with Scala.js or any of the other languages that compile to JS. TypeScript is one option among many. The appeal of TypeScript is that it fixes some things about JavaScript rather than throwing the language away. That's useful because it allows teams to transition from one to the other gradually. Facebook had to do the same thing with PHP, so they created Hack.
  - tkubacki 10y ago
    "then TS would remove that syntax." So there is no hard promise of TS backward compatibility ? Sorry but whole TS looks like another EEE - MS will/can argue on some further JS changes for/against based on existing TS codebase. I hope I'm wrong here though.

DanRosenwasser 10y ago

Actually TypeScript powers a JS editing experience codenamed "Salsa" that uses JSDoc comments for types. You can try it out in VS Code where it should currently be enabled. Give that a shot if you're looking into that sort of workflow.

abritinthebay 10y ago
> uses JSDoc comments for types oh god... shivers... ;) No, that sounds neat but I loathe JSDoc/JavaDoc derived formats. Good idea for someone else though!