13 ms·

Flow vs. Typescript

244 points by dmnd 10y ago

tinza123 10y ago
TypeScript 2.0 added control-flow based analysis, therefore cases like the one in slide 12 will be cached with the `strictNullChecks` flag.
abritinthebay 10y ago
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!
solomatov 10y ago
The best things about flow which typescript doesn't have is sound typesystem. I hope typescript will adopt it at some point in time.
- hoodunit 10y ago
  One area in which Flow may be "technically" sound but it feels illogical is how in how it infers certain types. TypeScript requires that a variable has one type that doesn't change, but Flow will infer multiple types for a variable at different points in the code depending on how it is used. Also because Flow infers types based on how they are used, there are some interesting situations where you would expect the type checker to complain but it doesn't. E.g. if you have an object with a field that is never used, Flow won't complain about the field even if it is not defined in the type of the object. Overall I feel like TypeScript enforces logical, opinionated defaults, while Flow is happier to go with the illogical structure of your own usage (while enforcing opinionated defaults in other areas like null-checking).
  - alectic 10y ago
    Jeff here (I work on Flow). I talked a bit about why we infer unions in this way in my ReactEU talk earlier this week (https://www.youtube.com/watch?v=VEaDsKyDxkY https://www.youtube.com/watch?v=VEaDsKyDxkY). Ultimately it boils down to the notion that inference is about understanding the type, and annotations are about expressing it. If you write a type annotation for a variable, then Flow will of course not infer anything more or less than your annotation. If, however, you use the variable as multiple types (but do so in a way that is clearly safe), Flow infers the union so that it doesn't give you errors for code that is clearly ok. I think the example from the talk was something like: var name = "Jeff"; name = name.toUpperCase(); // safe if (loggedOut) { name = null; // safe } var firstInitial = name ? name[0] : null; // safe The above code has no errors in it, and because flow infers `name` as a type `null | string`, Flow is able to verify its safety and thus doesn't error. OTOH, if we use an annotation to express the type of `name` as intended as only `string`, then we would get an error on the null assignment: thing like: var name: string = "Jeff"; name = name.toUpperCase(); if (loggedOut) { name = null; // Error! } var firstInitial = name ? name[0] : null; So in summary: Inference is the means by which Flow understands, annotations are the means by which you express to Flow your intentions.
gear54rus 10y ago
So today is typed JS day? https://i.imgur.com/XAEeEFm.png https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain? I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools? Are there properly working code formatters for both? What about editor support (Sublime)? I also understood that TS is a superset of ES6, what is Flow's relationship with ES6+?
- TheCoreh 10y ago
  They both aim to be JavaScript supersets, so in theory all your code should already work. In practice some of the things you're currently doing will probably upset the type checks. Nothing particularly hard to fix, and you could only use them on new files, or move files over gradually. If you're targetting ES5 with Babel, you can have TypeScript output ES6, and then pass that through babel. All libs should work fine, but you will not get all the benefits of the type checking if you don't install type definitions for them (some libs already come with those, though). There really isn't a lot to lose. If you ever feel like it was not a good fit for your project, you can run your code though TypeScript, targetting ES6, and it will produce pretty much the same code without the type annotations.
- chadaustin 10y ago
  I haven't used Flow (we actually couldn't get it to work with our build system in a few days and gave up, because TypeScript was easy). We integrated replaced Babel with TypeScript in about one day, and ported the entire codebase from ES6 to TS in about two or three days. The code looks almost identical except for the type annotations, which we were documenting in comments anyway. Also, you can pretty much switch right back to Babel if you want, since Babel will ignore type annotations. Editor support for TS is amazing. Both Atom and VS Code have great autocompletion and live typechecking as you edit. Build times with TS are okay. Our codebase rebuilds with ts-loader in webpack within something like 4 seconds upon saving. I'd prefer half a second of course. We have had no problem using any existing JS code. You can provide type annotations or not, but you don't have to. We use React, moment.js, underscore, jQuery. All the major libraries have type bindings. We also use some internal CoffeeScript libraries and occasionally bother providing type bindings, but usually not. In short, TypeScript is great and if you're going to adopt ES6 you might as well adopt TypeScript too.
OmarIsmail 10y ago
No matter which one you go with if you're project is going to live for any decent length of time please use one of these. Typed Javascript plugs many holes in the language and there is a qualitative positive difference in productivity. Just go with one of them. Seriously.
Skinney 10y ago
The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).
- deleted 10y ago
  [deleted]
- spicyj 10y ago
  Windows support is coming soon; the Flow team is actively working on it -- so hopefully you'll see something in a few weeks.
  - Bakesteve 10y ago
    thats great. Though I would add in the flow vs TS debate the level of community suport / openness is (currently) hugely in typescripts favour, and for a tool that you are going to embed inot a lot of your files, so a reasonable effort to unwind, that matters. If you compare: https://github.com/Microsoft/TypeScript/milestones https://github.com/Microsoft/TypeScript/milestones and https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap to the lack of information on progress from the flow team, especially on the win support issue https://github.com/facebook/flow/issues/6 https://github.com/facebook/flow/issues/6
  - coke12 10y ago
    Off topic, but what's the current status of flow-replacing-PropTypes?
- greenspot 10y ago
  Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?
msoad 10y ago
Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20
- bsimpson 10y ago
  I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don't remember the ramifications of this, but I think one was it makes Flow easier to work with/require less boilerplate. If you set types on your exports, Flow can infer the stuff in the middle. Flow is also compatible with prototype chains; whereas, TypeScript only knows about ES2015 classes (unless you declare types separately in t.ds files). - Because TypeScript is a compiler, they can define their own syntax. Flow, on the other hand, tries to be compatible with pure JavaScript. (You can define Flow annotations in comments to avoid needing a tool like Babel.) This means the syntax for certain operations is a bit more verbose in Flow: I think the nullable operator was one case, where the operator Microsoft chose could be ambiguous with JavaScript code in Flow, so Facebook chose a different one. In short, there are inherent architectural differences that make the two incompatible - there can be edge cases that make a file that works in one not work in the other. The two teams share notes and try to avoid divergence when possible, but as the slideshow shows, the projects have different aims, which can yield conflicting decisions. If Microsoft adds support for the Flow nullability operator, there ought to be a large subset of shared syntax between the two, where files that work in one should work in the other, if you set TypeScript to use Flow's defaults and don't rely on nominal typing. These are all notes off the top of my head from last week. I haven't used either tool yet. Please feel free to correct any mischaracterizations.
  - itsyogesh 10y ago
    I know I sound a little ignorant, but could you elaborate a little on nullability. I mean is it the same as checking whether an assignment is null or not? P.S. I haven't used either typescript or flow.
greenspot 10y ago
I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently: yes
- Hurtak 10y ago
  > - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one
  - yuchi 10y ago
    But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.
  - cageface 10y ago
    The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.
    - RX14 10y ago
      It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal (http://crystal-lang.org/ http://crystal-lang.org/)
      - cageface 10y ago
        Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.
Matthias247 10y ago
Regarding the first class definition with TS (sayer): You can shorten the it by declaring the public variable within the constructor: constructor(public this.what: string) {}. Thereby you can eliminate the property declaration as well as the assignment inside the constructor. And regarding the non-nullable example for Typescript: I think there is an non-implicit-returns option or something similar for the compiler which would have warned you that the function is incomplete. Of course it wouldn't help if you manually return null/undefined (which is valid).
robinricard 10y ago
Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you just start the project and you use VSCode, TS seems to be a strongest choice. Depends on what you do, but both tools are great, whatever you choose, typechecking is worth in javascript if you need more reliability and maintainability.
- hoodunit 10y ago
  I actually found the opposite was true in our project - TypeScript was easier to add into the code than Flow. The biggest reason for this was that Flow demands null/undefined checking and null was used extensively throughout this code base. With TypeScript, on the other hand, the changes to make it work initially amounted to sprinkling a few "any" notations and making some explicit object interfaces at various points.
  - shados 10y ago
    Flow supports nullable types just fine, and flow in weak mode doesn't mandate any annotation whatsoever.
michaelwww 10y ago
Slide 12 is incorrect. TypeScript does catch this with a "not all control paths return a value"
Hurtak 10y ago
I heard somewhere, that TS class syntax diverged somewhat from the spec. Can anybody who has insight into the TS tell me what the situation is?
chvid 10y ago
I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type 'number' is not assignable to type 'string'. obj = 10; I simply don't write code like that. The crucial difference is that I would pick a variable name that made it obvious what goes in it: let text = 'yo'; // This line here - I would not in practice write as 10 obviously does not belong in text: text = 10; (similarly I would never use the variable name 'what')
- Maro 10y ago
  Things change when you're working on a 1-10M LOC codebase , with 1-10K other engineers, like big companies do. Eg. Flow was written at Facebook (where I work).
- humanfromearth 10y ago
  Like the presentation said, if you have a small project then don't use type checking. If you work in a big project with a lot of code that you didn't write then it could help a lot. Also you don't have to use it everywhere with Flow.
- adamors 10y ago
  How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduce because the codebase is large and challenging to work with, mostly because Javascript. There's only so much you can do with best practices and code organisation.
  - chvid 10y ago
    I work on / have worked on fairly big projects. Plenty of them have been "a challenge to work with". Always because of the code that had been written (+ other things). Never because of the language. For me the trick to big projects is strong modularisation and well-defined interfaces which you can do regardless if you have static type checks or not.
fridek 10y ago
I think the biggest loser in this comparison is Closure Compiler, which is around for years with all those features. It's also still active with development on understanding and transpiling ES6 and even TypeScript from what I've heard [1]. There also made a good move recently, enabling ES6 modules packages instead of its own goog.provide/goog.require. Yet, the available toolchain for it is years behind others. If you wonder how you should have any live reload development with it, you can either rely on community plugins like grunt-closure-compiler [2] or hope plovr[3] is finally resurrected back to a state where it's usable. This all sounds fine until you think about any unit testing. The only karma runner[4] for closure is simply broken and unmaintained. Even worse, most of npm packages you might want to compile with your code will output thousands of errors because there is no clear way to whitelist code as "not my code leave it alone". I can just hope one day Google will publish a yeoman generator with all those things solved and get it back in the game. [1] https://groups.google.com/forum/#!msg/closure-compiler-discuss/5EVAw6oO2BI/LI9ptKLnCYoJ https://groups.google.com/forum/#!msg/closure-compiler-discu... [2] https://github.com/gmarty/grunt-closure-compiler https://github.com/gmarty/grunt-closure-compiler [3] https://github.com/bolinfest/plovr https://github.com/bolinfest/plovr [4] https://github.com/karma-runner/karma-closure https://github.com/karma-runner/karma-closure
runn1ng 10y ago
From my experience - Flow is still very "unstable" and in heavy development. I haven't tried TypeScript at all, so I cannot compare that. It's absolutely true that Flow team is merging all pull good requests, fixing issues (the backlog is big - 500 issues - but TypeScript has 1000, so it's not incomparable) and the system is made dramatically better every release. But there are still rough edges, especially when working with ES6 modules and import/requires/etc. Again, I don't know how TypeScript compares, I learned Flow and am just using that.
- whatever_dude 10y ago
  The good thing TypeScript has going for it is tooling. It's really solid. IMO, VSC is a pleasure, and the tools (tsc, tslint, etc) are extremely stable. Things don't break. The GitHub community is going really fast, and I love reading some of the PRs, but it's hard for me to compare in that sense.
avodonosov 10y ago
Where I saw the same nullable / non-nullable values: Kotlin. Bidning animals = cats is problematic only if the collection is mutable. Forbidding that is too limiting when you work with immutable collections (even it that's an Array - if you are not going to mutate it).
whatever_dude 10y ago
Good presentation. But two caveats: First, the slides about lack of non-nullable types in TypeScript are incorrect, if you count the beta ("next") versions. It's already part of 2.0 [1] which should be out soon [2]. He says "there is hope" but it's more than hope, it's a certainty. (the date of the presentation is not clear, but seems outdated to me) Second, there's a lot of other features that are left out. Union types, flexible interfaces, etc. They're not on par between the two languages, but many of those are almost as helpful as types, just more specific, so they're important if one is trying to draw a comparison. [1] https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 [2] https://github.com/Microsoft/TypeScript/milestones https://github.com/Microsoft/TypeScript/milestones
CuriousSkeptic 10y ago
One aspect to consider before jumping into TS or Flow. As is the nature of any type system they rule out some programs that are perfectly fine. A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And/or helping the typer by casting to known types it failed to recognize. And it will work fine, after all this is precisely what you do with untyped ES (in your head). This workaround was to strong of a code smell to just let things be like that though. So I've found myself spending time inventing ways to refactor code, or alter type definitions, to get proper typing instead. This can eat up time better spent implementing features. Not everyone will have this problem, but if you're anything like me, do consider it before adopting these. As a less intrusive option, consider using eslint with Babel and reference checking for modules. Not in any way a complete type-system, but might be just enough if you're allready comfortable with ES as it is.
- lobo_tuerto 10y ago
  Do you have a specific (and simple, if possible) example at hand?
  - CuriousSkeptic 10y ago
    Redux perhaps. Spent some time inventing a way to pass event types to reducers. Turns out I reinvented redux-act in the end ;)
cabalamat 10y ago
This would be a good deal less irritating if it was written as an essay and not a slideshow.
- choward 10y ago
  I'm so sick of being linked to slide shows. Slideshows are worthless on their own. They either need a presentation to go with them or be presented in a different format.
- untog 10y ago
  You could always rewrite it yourself. Not every submission to HN was created as or intended for a Hacker News audience. The author wasn't under any obligation to publish their slides, personally I'm glad they did.
  - cabalamat 10y ago
    > Not every submission to HN was created as or intended for a Hacker News audience That's a good point.
moomin 10y ago
If you really want good types with your JS, there's always Purescript. (I'm half serious.)
bkad 10y ago
Love the use of Zenburn in the syntax highlighting :)
karmakaze 10y ago
Flow is more strict than TypeScript as demonstrated by the slides. As such why not use it as a static checker for TypeScript? I don't see it so much as a vs. situation. Unless you mean to use the unsafe area in what is valid TypeScript and invalid Flow.
DJCordhose 10y ago
What TypeScript 2.0 promises: https://www.infoq.com/news/2016/04/typescript-2-preview https://www.infoq.com/news/2016/04/typescript-2-preview
DJCordhose 10y ago
What currently is in TypeScript: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

244 points by dmnd 10y ago

TypeScript 2.0 added control-flow based analysis, therefore cases like the one in slide 12 will be cached with the `strictNullChecks` flag.

abritinthebay 10y ago

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!

solomatov 10y ago

The best things about flow which typescript doesn't have is sound typesystem. I hope typescript will adopt it at some point in time.

hoodunit 10y ago
One area in which Flow may be "technically" sound but it feels illogical is how in how it infers certain types. TypeScript requires that a variable has one type that doesn't change, but Flow will infer multiple types for a variable at different points in the code depending on how it is used. Also because Flow infers types based on how they are used, there are some interesting situations where you would expect the type checker to complain but it doesn't. E.g. if you have an object with a field that is never used, Flow won't complain about the field even if it is not defined in the type of the object. Overall I feel like TypeScript enforces logical, opinionated defaults, while Flow is happier to go with the illogical structure of your own usage (while enforcing opinionated defaults in other areas like null-checking).
- alectic 10y ago
  Jeff here (I work on Flow). I talked a bit about why we infer unions in this way in my ReactEU talk earlier this week (https://www.youtube.com/watch?v=VEaDsKyDxkY https://www.youtube.com/watch?v=VEaDsKyDxkY). Ultimately it boils down to the notion that inference is about understanding the type, and annotations are about expressing it. If you write a type annotation for a variable, then Flow will of course not infer anything more or less than your annotation. If, however, you use the variable as multiple types (but do so in a way that is clearly safe), Flow infers the union so that it doesn't give you errors for code that is clearly ok. I think the example from the talk was something like: var name = "Jeff"; name = name.toUpperCase(); // safe if (loggedOut) { name = null; // safe } var firstInitial = name ? name[0] : null; // safe The above code has no errors in it, and because flow infers `name` as a type `null | string`, Flow is able to verify its safety and thus doesn't error. OTOH, if we use an annotation to express the type of `name` as intended as only `string`, then we would get an error on the null assignment: thing like: var name: string = "Jeff"; name = name.toUpperCase(); if (loggedOut) { name = null; // Error! } var firstInitial = name ? name[0] : null; So in summary: Inference is the means by which Flow understands, annotations are the means by which you express to Flow your intentions.

gear54rus 10y ago

So today is typed JS day? https://i.imgur.com/XAEeEFm.png https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain? I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools? Are there properly working code formatters for both? What about editor support (Sublime)? I also understood that TS is a superset of ES6, what is Flow's relationship with ES6+?

TheCoreh 10y ago
They both aim to be JavaScript supersets, so in theory all your code should already work. In practice some of the things you're currently doing will probably upset the type checks. Nothing particularly hard to fix, and you could only use them on new files, or move files over gradually. If you're targetting ES5 with Babel, you can have TypeScript output ES6, and then pass that through babel. All libs should work fine, but you will not get all the benefits of the type checking if you don't install type definitions for them (some libs already come with those, though). There really isn't a lot to lose. If you ever feel like it was not a good fit for your project, you can run your code though TypeScript, targetting ES6, and it will produce pretty much the same code without the type annotations.
chadaustin 10y ago
I haven't used Flow (we actually couldn't get it to work with our build system in a few days and gave up, because TypeScript was easy). We integrated replaced Babel with TypeScript in about one day, and ported the entire codebase from ES6 to TS in about two or three days. The code looks almost identical except for the type annotations, which we were documenting in comments anyway. Also, you can pretty much switch right back to Babel if you want, since Babel will ignore type annotations. Editor support for TS is amazing. Both Atom and VS Code have great autocompletion and live typechecking as you edit. Build times with TS are okay. Our codebase rebuilds with ts-loader in webpack within something like 4 seconds upon saving. I'd prefer half a second of course. We have had no problem using any existing JS code. You can provide type annotations or not, but you don't have to. We use React, moment.js, underscore, jQuery. All the major libraries have type bindings. We also use some internal CoffeeScript libraries and occasionally bother providing type bindings, but usually not. In short, TypeScript is great and if you're going to adopt ES6 you might as well adopt TypeScript too.

OmarIsmail 10y ago

No matter which one you go with if you're project is going to live for any decent length of time please use one of these. Typed Javascript plugs many holes in the language and there is a qualitative positive difference in productivity. Just go with one of them. Seriously.

Skinney 10y ago

The main problem for me, is that Flow doesn't support Windows (yet?). I've been working solo on a frontend a couple of months now, and the team has just been extended with a new developer (yay). However, he uses Windows, and so all my type annotations are worthless. We're making the switch to TypeScript once 2.0 is released (easier to port with strictNullChecks).

deleted 10y ago
[deleted]
spicyj 10y ago
Windows support is coming soon; the Flow team is actively working on it -- so hopefully you'll see something in a few weeks.
- Bakesteve 10y ago
  thats great. Though I would add in the flow vs TS debate the level of community suport / openness is (currently) hugely in typescripts favour, and for a tool that you are going to embed inot a lot of your files, so a reasonable effort to unwind, that matters. If you compare: https://github.com/Microsoft/TypeScript/milestones https://github.com/Microsoft/TypeScript/milestones and https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap to the lack of information on progress from the flow team, especially on the win support issue https://github.com/facebook/flow/issues/6 https://github.com/facebook/flow/issues/6
- coke12 10y ago
  Off topic, but what's the current status of flow-replacing-PropTypes?
greenspot 10y ago
Really wondering: who is developing Node/JS on Windows nowadays? Not that I don't like Windows (I like W10 + the new Ubuntu within efforts a lot), but the ecosystem around Node is so much tailored around Linux. Even with OSX where we have an excellent support, there's still some slight friction when deploying to Ubuntu. Or is Windows 10 a viable alternative for Node devs?

msoad 10y ago

Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20

bsimpson 10y ago
I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don't remember the ramifications of this, but I think one was it makes Flow easier to work with/require less boilerplate. If you set types on your exports, Flow can infer the stuff in the middle. Flow is also compatible with prototype chains; whereas, TypeScript only knows about ES2015 classes (unless you declare types separately in t.ds files). - Because TypeScript is a compiler, they can define their own syntax. Flow, on the other hand, tries to be compatible with pure JavaScript. (You can define Flow annotations in comments to avoid needing a tool like Babel.) This means the syntax for certain operations is a bit more verbose in Flow: I think the nullable operator was one case, where the operator Microsoft chose could be ambiguous with JavaScript code in Flow, so Facebook chose a different one. In short, there are inherent architectural differences that make the two incompatible - there can be edge cases that make a file that works in one not work in the other. The two teams share notes and try to avoid divergence when possible, but as the slideshow shows, the projects have different aims, which can yield conflicting decisions. If Microsoft adds support for the Flow nullability operator, there ought to be a large subset of shared syntax between the two, where files that work in one should work in the other, if you set TypeScript to use Flow's defaults and don't rely on nominal typing. These are all notes off the top of my head from last week. I haven't used either tool yet. Please feel free to correct any mischaracterizations.
- itsyogesh 10y ago
  I know I sound a little ignorant, but could you elaborate a little on nullability. I mean is it the same as checking whether an assignment is null or not? P.S. I haven't used either typescript or flow.

greenspot 10y ago

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS': - if your project does not live for long: no - if your project is really simple: no - if there is a chance you will need to refactor the thing: yes - if your system is very important or even crucial for the success of your company: yes - if people enter or leave your team frequently: yes

Hurtak 10y ago
> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one
- yuchi 10y ago
  But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.
- cageface 10y ago
  The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.
  - RX14 10y ago
    It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal (http://crystal-lang.org/ http://crystal-lang.org/)
    - cageface 10y ago
      Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.

Matthias247 10y ago

Regarding the first class definition with TS (sayer): You can shorten the it by declaring the public variable within the constructor: constructor(public this.what: string) {}. Thereby you can eliminate the property declaration as well as the assignment inside the constructor. And regarding the non-nullable example for Typescript: I think there is an non-implicit-returns option or something similar for the compiler which would have warned you that the function is incomplete. Of course it wouldn't help if you manually return null/undefined (which is valid).

robinricard 10y ago

Both systems are really great, however, when adding typechecking into an existing codebase, flow does offer more flexibility thanks to weak checking and annotation comments. You can really progressively add typechecking by just dropping the tool in the codebase. Also, if you subscribe to Facebook's tooling (Nuclide especially), you will end up with great tools (jump to def, integrated checking, ...). However if you just start the project and you use VSCode, TS seems to be a strongest choice. Depends on what you do, but both tools are great, whatever you choose, typechecking is worth in javascript if you need more reliability and maintainability.

hoodunit 10y ago
I actually found the opposite was true in our project - TypeScript was easier to add into the code than Flow. The biggest reason for this was that Flow demands null/undefined checking and null was used extensively throughout this code base. With TypeScript, on the other hand, the changes to make it work initially amounted to sprinkling a few "any" notations and making some explicit object interfaces at various points.
- shados 10y ago
  Flow supports nullable types just fine, and flow in weak mode doesn't mandate any annotation whatsoever.

michaelwww 10y ago

Slide 12 is incorrect. TypeScript does catch this with a "not all control paths return a value"

Hurtak 10y ago

I heard somewhere, that TS class syntax diverged somewhat from the spec. Can anybody who has insight into the TS tell me what the situation is?

chvid 10y ago

I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type 'number' is not assignable to type 'string'. obj = 10; I simply don't write code like that. The crucial difference is that I would pick a variable name that made it obvious what goes in it: let text = 'yo'; // This line here - I would not in practice write as 10 obviously does not belong in text: text = 10; (similarly I would never use the variable name 'what')

Maro 10y ago
Things change when you're working on a 1-10M LOC codebase , with 1-10K other engineers, like big companies do. Eg. Flow was written at Facebook (where I work).
humanfromearth 10y ago
Like the presentation said, if you have a small project then don't use type checking. If you work in a big project with a lot of code that you didn't write then it could help a lot. Also you don't have to use it everywhere with Flow.
adamors 10y ago
How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduce because the codebase is large and challenging to work with, mostly because Javascript. There's only so much you can do with best practices and code organisation.
- chvid 10y ago
  I work on / have worked on fairly big projects. Plenty of them have been "a challenge to work with". Always because of the code that had been written (+ other things). Never because of the language. For me the trick to big projects is strong modularisation and well-defined interfaces which you can do regardless if you have static type checks or not.

fridek 10y ago

I think the biggest loser in this comparison is Closure Compiler, which is around for years with all those features. It's also still active with development on understanding and transpiling ES6 and even TypeScript from what I've heard [1]. There also made a good move recently, enabling ES6 modules packages instead of its own goog.provide/goog.require. Yet, the available toolchain for it is years behind others. If you wonder how you should have any live reload development with it, you can either rely on community plugins like grunt-closure-compiler [2] or hope plovr[3] is finally resurrected back to a state where it's usable. This all sounds fine until you think about any unit testing. The only karma runner[4] for closure is simply broken and unmaintained. Even worse, most of npm packages you might want to compile with your code will output thousands of errors because there is no clear way to whitelist code as "not my code leave it alone". I can just hope one day Google will publish a yeoman generator with all those things solved and get it back in the game. [1] https://groups.google.com/forum/#!msg/closure-compiler-discuss/5EVAw6oO2BI/LI9ptKLnCYoJ https://groups.google.com/forum/#!msg/closure-compiler-discu... [2] https://github.com/gmarty/grunt-closure-compiler https://github.com/gmarty/grunt-closure-compiler [3] https://github.com/bolinfest/plovr https://github.com/bolinfest/plovr [4] https://github.com/karma-runner/karma-closure https://github.com/karma-runner/karma-closure

runn1ng 10y ago

From my experience - Flow is still very "unstable" and in heavy development. I haven't tried TypeScript at all, so I cannot compare that. It's absolutely true that Flow team is merging all pull good requests, fixing issues (the backlog is big - 500 issues - but TypeScript has 1000, so it's not incomparable) and the system is made dramatically better every release. But there are still rough edges, especially when working with ES6 modules and import/requires/etc. Again, I don't know how TypeScript compares, I learned Flow and am just using that.

whatever_dude 10y ago
The good thing TypeScript has going for it is tooling. It's really solid. IMO, VSC is a pleasure, and the tools (tsc, tslint, etc) are extremely stable. Things don't break. The GitHub community is going really fast, and I love reading some of the PRs, but it's hard for me to compare in that sense.

avodonosov 10y ago

Where I saw the same nullable / non-nullable values: Kotlin. Bidning animals = cats is problematic only if the collection is mutable. Forbidding that is too limiting when you work with immutable collections (even it that's an Array - if you are not going to mutate it).

whatever_dude 10y ago

Good presentation. But two caveats: First, the slides about lack of non-nullable types in TypeScript are incorrect, if you count the beta ("next") versions. It's already part of 2.0 [1] which should be out soon [2]. He says "there is hope" but it's more than hope, it's a certainty. (the date of the presentation is not clear, but seems outdated to me) Second, there's a lot of other features that are left out. Union types, flexible interfaces, etc. They're not on par between the two languages, but many of those are almost as helpful as types, just more specific, so they're important if one is trying to draw a comparison. [1] https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20 [2] https://github.com/Microsoft/TypeScript/milestones https://github.com/Microsoft/TypeScript/milestones

CuriousSkeptic 10y ago

One aspect to consider before jumping into TS or Flow. As is the nature of any type system they rule out some programs that are perfectly fine. A workaround for this is to infer, or explicitly annotate, things to be dynamically typed. And/or helping the typer by casting to known types it failed to recognize. And it will work fine, after all this is precisely what you do with untyped ES (in your head). This workaround was to strong of a code smell to just let things be like that though. So I've found myself spending time inventing ways to refactor code, or alter type definitions, to get proper typing instead. This can eat up time better spent implementing features. Not everyone will have this problem, but if you're anything like me, do consider it before adopting these. As a less intrusive option, consider using eslint with Babel and reference checking for modules. Not in any way a complete type-system, but might be just enough if you're allready comfortable with ES as it is.

lobo_tuerto 10y ago
Do you have a specific (and simple, if possible) example at hand?
- CuriousSkeptic 10y ago
  Redux perhaps. Spent some time inventing a way to pass event types to reducers. Turns out I reinvented redux-act in the end ;)

cabalamat 10y ago

This would be a good deal less irritating if it was written as an essay and not a slideshow.

choward 10y ago
I'm so sick of being linked to slide shows. Slideshows are worthless on their own. They either need a presentation to go with them or be presented in a different format.
untog 10y ago
You could always rewrite it yourself. Not every submission to HN was created as or intended for a Hacker News audience. The author wasn't under any obligation to publish their slides, personally I'm glad they did.
- cabalamat 10y ago
  > Not every submission to HN was created as or intended for a Hacker News audience That's a good point.

moomin 10y ago

If you really want good types with your JS, there's always Purescript. (I'm half serious.)

bkad 10y ago

Love the use of Zenburn in the syntax highlighting :)

karmakaze 10y ago

Flow is more strict than TypeScript as demonstrated by the slides. As such why not use it as a static checker for TypeScript? I don't see it so much as a vs. situation. Unless you mean to use the unsafe area in what is valid TypeScript and invalid Flow.

DJCordhose 10y ago

What TypeScript 2.0 promises: https://www.infoq.com/news/2016/04/typescript-2-preview https://www.infoq.com/news/2016/04/typescript-2-preview

DJCordhose 10y ago

What currently is in TypeScript: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...