Flow vs. Typescript

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

Right, that check-list is actually useful in any dynamically-VS-statically typed decision scenario.

These are the sort of things you could argue in favor of using GWT.

Windows support is coming soon; the Flow team is actively working on it -- so hopefully you'll see something in a few weeks.

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?

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.

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.

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

> 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?

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

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.

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

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.

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.

Types are invaluable when refactoring your code. I have found Typescript to be invaluable when doing exploratory programming as it allows me to refactor heavily as I learn more about the structure of the problem. The compiler points all the affected code sites and I have reasonable confidence in the correctness of the code after the refactor.

I used to be like that, but after a lot of JS programming I ended up with WebStorm and very heavily using JSDoc and Closure compiler syntax inline type-comments - which together with WebStorm give me almost TypeScript-like type checks. There is not a variable or function parameter declaration without a type in my code now.

Example (the inline type info is Closure compiler syntax, with the "@" it's JSDoc):

    /**
     * @typedef {Object} MyResultType
     * @property {string} example
     * @property {Function} exampleFn
     */

    const /**string[]*/ myPromise = Promise.resolve(['','']);
    const /**MyResultType*/ t = myPromise.then(
        /**string[]*/ a => a.map(/**string*/ s => s.toUpperCase())
    );

Or a more lengthy JSDoc comment when I need to document a variable anyway:

    /**
      * This is a very important and beautiful variable
      * @type string[]
      */
    const myPromise = Promise.resolve(['','']);

I have a lot of complex return types - meaning an object instead of a simple type, because a function can only return one value and I often have to return more than that. I also have lots of promises (also as return values), and it's easy to get confused which function returns a result synchronously and which one asynchronously.

Sync. vs. async. isn't something logical and obvious - it's determined by where you get data from. No coding construct won't change that we have to keep the hardware in mind and concentrate on just the algorithm when we don't have blocking function calls, "yield" and "async" don't change that, we have to remember to add them. So having difficulty remembering which function returns the result this or that way has nothing to do with the algorithm and I appreciate the IDE (in my case, or TypeScript in others) keeping track of the types.

Even though I don't use TypeScript I use TypeScript "DefinitelyTyped" interface definitions for things like Node and Mocha - WebStorm uses them for its behind the scenes type-checking.

By religiously always adding a type even when it seems obvious I get WebStorm to report when a type doesn't match what it determined should be there, and it's meta-information for myself. It always ensures that I always get correct auto-completion suggestions and inspection warnings - because the IDE isn't always capable of resolving all variables. Especially when it's promises created in another module and after the n-th chain element and in connection with arrow functions and parameter destructuring the IDE often gives up, there still are gaps in its ability to find the intended type since those constructs are too new. However, each time I find a hole I file a bug report and the JetBrains team almost fixes it pretty quickly for the next version. "Flow" is supported too. Example for the type of bugs one may find, and how a type inspection error looks like (randomly picked from the bug list): https://youtrack.jetbrains.com/issue/WEB-21839#u=14643829544... (that bug has been fixed)

I did a little bit of TypeScript, WebStorm support is very good there too. I try to avoid adding a compilation step but it sure looks tempting - and just a year or two ago I was adamantly against it as "useless". Well, my attitude has changed after having fond types very convenient on a large exploratory project where I often have to revisit and refactor and often completely rewrite previously written code and/or restructure large sections and multiple modules at a time.

I'm not saying you absolutely must use types, it's just that many people incl. myself find it more convenient, and in my case I even was in the other camp for the longest time.

undefined is not a function

Primitive types such as string/number/... are really not a great example when it comes to showcasing the benefits of static typing. I don't know why it's so common.

A better example would be something like

    // let's pretend the values are not dummy values, etc.
    function getWeather(encodedWeatherString) {
        return { temperature: 50, windDirection: 'east' }
    }
    
    function getWeatherFromUrl(url) {
        return { temperature: 20, windDirection: 'east' }
    }

All is well. Some time later, someone decides to add some extra data to getWeatherFromUrl, but not to getWeather, and then tries to use this extra data in some place, i.e.:

    function getWeatherFromUrl(url) {
        return { temperature: 20, windDirection: 'east', time: new Date() }
    }
    
    function displayWeather(weather) {
        return "It was " + weather.temperature + " on " + dayOfWeek(weather.time.getDay())
    }

Which will cause an error when called on the weather object returned from getWeather(), because the time property will be undefined.

This is of course a tiny tiny example where it is trivial to keep track of all the data structures in your head. But even in projects that are not that huge, it can get pretty inconvenient and mentally draining very fast. It's a lot more enjoyable to not have to deal with that kind of stuff, and just have one Weather structure defined for the whole project that everything has to adhere to and that everything can rely on.

I agree I don't miss types too much when the amount of code is small. However, when you have thousands of lines of code including code you didn't write and JavaScript spits out a "undefined is not a function" error in the middle of running a complex program, static typing can save you a huge amount of time and sanity.

Also, what are you losing by introducing strong types? Why wouldn't you want the compiler to verify the logic you're keeping track of manually?

You're not the only one. It's a common sentiment if you haven't really, fully used a type system before.

If there's an important property you want your program to have, and you can express it using the type system, then your compiler can prove it for you. For example, if you have an Employee record with a jobTitle field of type String, then it's hard to be certain you'll never get an invalid jobTitle. If you change that to a type hierarchy with subtypes like Manager, Developer, etc. then once the program compiles, you can be certain that particular error can't happen at run time. As type systems grow more sophisticated, more program properties can be represented as types.

If you want to experience it, perhaps try a language with a really top-notch type system like OCaml or Haskell. Maybe try implementing some kind of transpiler from json to json that uses the type system to describe the valid input. You'll have a collection of parsing functions that detect all the errors, and then the rest of the system can rest assured that the parsed representation is error-free, and you can be certain that you never forgot to handle one of the possible cases. (OCaml, in particular, is very good at this.)

If you try this, and you're human, I think you'll make a few mistakes that get caught by the type checker.

Every time I have to wade into a legacy dynamic codebase I find all kinds of type errors that aren't caught by tests. That's bad enough on its own but refactoring without support from a type checker is a pure high wire act.

Next time you spend hours looking for a strange bug that turned out to be a honest-to-god misspelling, think about how you wouldn't have had that bug in the first place if you were using static typing.

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.

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.

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.

> Flow or TS being opinionated

Neither is opinionated. They have some pretty uncontroversial (similar to other popular languages) typing on top of JS, and it's all opt-in. If there's something you don't like, you don't have to use it.

> and their impact on an established toolchain?

I don't know about Flow, but TypeScript is very easy to integrate into an existing chain. If you're using something like Gulp, there is a pure JS library that you can call to transpile your TS into JS. If you use Babel, you can simply insert the TS->JS transpilation before you call Babel.

TypeScript has an executable called tsc that you can use to transpile your TS whenever the file is changed. You can use that, and then your tool chain doesn't even have to change at all. (Automatic TypeScript transpilation is built into WebStorm and easy to add to VS Code.)

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

In my limited experience, TS is much more polished than Flow is. The tooling is mature, debugging works well, and the language is rapidly improved. It's not just MS using it -- Google also uses it, and some other larger companies.

> 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?

Anything (and I mean anything) you do with JS, you can also do with TS. It's a superset of JS and compiles to readable, idiomatic JS.

> Are there properly working code formatters for both?

WebStorm has mature formatting for TS, but there's also tslint if you want some additional error-checking. WebStorm has first-class support for TS, including integration with tslint.

> What about editor support (Sublime)?

No idea about Sublime, but WebStorm support is absolutely fantastic. Excellent debugging, hints, linting, and completion. VS Code is great, but it lacks some of the more niche-y features of the IntelliJ platform. Some people might not care, and VS Code will do everything they want.

Sublime TS support is top notch https://github.com/Microsoft/TypeScript-Sublime-Plugin

Flow is not a superset of any form of javascript. It is another language.

See: https://github.com/facebook/flow/issues/825

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.

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.

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.

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

Do you have a specific (and simple, if possible) example at hand?