Hacker News Reader

Comment by macrael | Hacker News Reader

I'd love a pro con from someone who's really tried out both TypeScript and Flow. I tried to get either of them started last weekend and couldn't get to a good place. Flow was missing annotations for three.js and typescript didn't seem to support es6isms. I found a compiler for the typescript definitions file for threejs but also couldn't sort out how to actually import that into flow.

View on HN

We did a very deep dive in comparison between the two before going with TypeScript. The biggest differences are:

1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions

2. Tooling, TypeScript has a much better tooling support

3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular.

Syntax and personal opinions was not part of our decision making process.

with the checkJs option, now you don't even need to rename your files to .ts, You can just use typescript as a nice typechecker and give you sane .js

Ok, I've used TS while contributing to OSS written with TS and I've used Flow extensively in production settings.

The main takeaway for me is that TS is much much less sound than Flow. That means it checks less invariants which in turn makes you less trust it...

Consider the following code which is valid (!) in TS:

    let promisedString: Promise<string> = new Promise(
      resolve => {
        // Perfectly valid in TypeScript!
        resolve(42)
      }
    )

Another downside of TS is poor type inference. It requires to annotate each top level function while Flow only requires to annotate exported functions.

Even the following simple piece of code will make TS ask you to annotate doAddition function:

    export function addition(a: number, b: number) {
      return doAddition(a, b)
    }

    function doAddition(a, b) {
      return a + b
    }

I'm really glad Flow doesn't force me into it.

Edit: spelling

FWIW your Promise example has to do with whatever implementation of Promise you're using, not Typescript. Bluebird's typings would correctly complain with that example -- both because your second Promise is implicit-any, and the resolve is wrong.

EDIT 2: This still surprises me...

   let promisedString: Promise<string> = new Promise<string>(
      resolve => {
        // Perfectly valid in TypeScript!
        resolve(undefined)
      }
    )

EDIT: no, I was wrong — Bluebird typings won't allow this behaviour but they force me to annotate both the binding and the Promise constructor call:

    let promisedString: Promise<string> = new Promise<string>(
      resolve => {
        resolve(42) // type error here, ok
      }
    )

That's surprising TS ships with such unsafe typings for ES2015 Promise API...

Hm... no.

First, note that this is with noImplicitAny activated. You can check this in TS playground.

Then if we inspect what typings TS have for ES2015 Promises[1] and for Bluebird[2], you can clearly see that those are identical in this case..

[1]: https://github.com/Microsoft/TypeScript/blob/master/lib/lib....

[2]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Er, I'm looking at it right now? I don't know what to tell you.

   error TS2322: Type 'Bluebird<{}>' is not assignable to type 'Bluebird<string>'.

And if I add the type parameter to the constructor...

   error TS2345: Argument of type '42' is not assignable to parameter of type 'string | Thenable<string>'

Re: your edit, you actually don't need that first typing. Typescript will infer the type of the promisedString.

> your edit, you actually don't need that first typing. Typescript will infer the type of the promisedString

Ok, but still this is confusing, it can't infer the type of RHS given the annotated LHS? Intuitively there's nothing wrong with it and Flow does that well...

Note this is similar to c# (and thinking about it, every OO language I can think of):

var cat = new Animal<Cat>(...); // yup! Animal<Cat> cat = new Animal(...); // Nope

I wonder if internally ts is treating these generic-accepting classes in the same way, where the generic is required?

Interestingly enough #1 seems more like another case of #2, because:

    let promisedString = new Promise<string>(
      resolve => {
        // Fails as expected in TypeScript!
        resolve(42)
      }
    )

Not sure — TS doesn't report any errors in the original code so I assume it thinks code is fine but it is not. That's totally different than #2.

I am not convinced that parameter type inference is a reason to use flow. I have seen examples where flow fails to report errors because it can't infer the parameter types. I would rather consistency over inference that sometimes works sometimes fails silently.

For example:

  function fn(a) {
    const {b} = a; 
  
    console.log(b.c);
  }
  fn({});

This compiles without errors - but would fail at runtime. https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVUCuA7AxgFwEs5swp...

Yep, reported to Flow issue tracker.

Uhhh nope. In TypeScript 2.2.2 your first example is definitely the error you'd expect.

Try it in the playground.

For your 1st example, it's failing because by explicitly annotating `promisedString` you are widening the type from the inferred `number` to `any`. If you remove the explicit annotation and let TS do its job, the code will fail (as expected) :).

For your second example - it's a divisive issue. I believe that a Hindley-Milner style type resolver (what Flow uses) is more usable, but there is a strong argument against it too [0].

[0] https://github.com/Microsoft/TypeScript/issues/15114

> by explicitly annotating `promisedString` you are widening the type from the inferred `number` to `any`

That's something I don't understand. Isn't that incorrect behaviour? Shouldn't TS try unify RHS and LHS?

TS is trying to unify RHS and LHS. TS follows a somewhat complicated widening process to unify unannotated generics, somewhat leaning towards ease of use over strictness. Adding additional strictness checks like noImplicitAny can help catch these situation. (In this case, it doesn't help, because the resolve argument is inferred `resolve: (value: any) => void` rather than `resolve: any` which would give a clear implicit any error. Inferred any in generic callbacks sound like a good strictness test to add...)

In this case in Typescript it is generally more strict to add a type annotation to the generic than the LHS:

  let promise = new Promise<string>((resolve) => resolve(42)) // This won't work

This is as much because the inference here that matters isn't between LHS and RHS but between generic arguments and function return inference.

> The main takeaway for me is that TS is much much less sound than Flow

And in personal anecdote-space I've experience the exact opposite :)

Well, I've provided examples where TS demonstrates unsound behaviour while Flow does well. What's your examples from personal anecdote-space?

I've tested your example and sure: That seems like a bug in the declaration of the Promise-class.

What I like about TypeScript and which I think is "sound" compared to Flow is the whole experience and how it is backed by good tooling.

With TypeScript I can open almost "any" editor and expect it to understand and respect the typings of all my TypeScript code. It will correctly autocomplete, and tell me when I'm using undefined members.

Basically with TypeScript every part of the stack seems to work for me, the developer, to ensure I make the right decisions and get the assistance I need, at all time. That makes it feel like a very safe and sound language to write code in.

With flow? Well fuck that. From what I can tell, you get almost nothing.

You can run your compiler and see if it validates, but I've seen almost no editor-support worth mentioning, meaning that while the type-inference in the compiler may occasionally be better (but for how long? TS has a ton of momentum), the overall experience feels much less sound and much more fragile. Much more unsafe.

The type-declarations definitely feel as important as the way they are declared: they're mere comments. They're not real.

Looks like the Promise example will be fixed in TypeScript 2.3.1

https://github.com/Microsoft/TypeScript/issues/14770

As far as type systems/language features:

TypeScript:

- Structurally typed

- Enum types

- Mapped types

- Abstract classes

- Scoped class members (public, private, protected)

- Namespaces

Flow:

- Nominally typed

- Covariance/contravariance annotations

- Supertype annotations (via $Supertype type)

- Subtype annotations (via $Subtype type)

- Arity annotations (via $Pred type)

- Subtraction types (via $Diff type)

- Opt-in 2-way type resolver (via * type)

- Refer to nested type (via $PropertyType type)

Otherwise, the two are remarkably similar.

I've been using TS for a few years, and Flow for a few months. Please correct me if any of the above are wrong.

In Flow only classes are nominally typed. Objects and interfaces are typed structurally.

Thank you for the comparison. This basically matches my experience as well. Hoping your post gets up to the top.

Flow is basically a linter, which I really don't like. If you run flow on an existing JS project it will find a few hundred not-really-bugs. That and the incredibly poor tooling (Flow runs as a separate server process) were enough to make me ditch it. On the other hand, if you use Typescript with the allowJs setting it's exactly ES6 plus optional types.

What es6 features were you looking for that TS didn't support? In general, it supports most stage 3 and higher ES proposals. (Note that TS doesn't polyfill methods; it only adds support for syntactic elements)

I suspect you didn't set target to ES6 in the `tsconfig.json` file which would limit some of the features. If you don't specify, I think the default is ES5. See this example:

https://github.com/styfle/react-server-example-tsx/blob/mast...

I haven't used Flow much, but having used TypeScript at work for only a few weeks we've already found several instances where the type system isn't flexible/complete enough to describe several perfectly valid JavaScript idioms. Workarounds often mean lots of `any` types or tons of boilerplate/repeated code. Not fun. On the whole, though, compared to un-typed JavaScript, still totally worth it. I'd just be interested to see how Flow handles some of these situations.

Do you have an example of one of these idioms that typescript can't handle?

Could you please post those situations? Someone familiar with Flow might be able to answer you.

I'd love a pro con from someone who's really tried out both TypeScript and ES6 Javascript. What exactly is the use case that TypeScript allows one to write JS for that one can't just write JS for?

I've been using both for a few years (TS at my old job, es6 at my new job but we're moving to TS so now I'm using both depending on what I'm working on).

The use case I like most about typescript is it makes refactoring and making changes really painless. For example, in an angular app, you may have a service that several components rely on. When changing a method signature in the service, you'll get compile-time info about any other usages of that service, and you feel a lot more confident about making changes without something dumb slipping through the cracks and causing bugs in production.

This confidence generally lends itself to less fear of change and more willingness to refactor, which leads to a better/cleaner codebase.

Aside from that, I love the JSDoc comments showing up as you type, especially if you're working on a team in which you may not know 100% what everyone has worked on.

Other features I use every day and love:

-automatic/generated import statements

-type definitions for libraries (most have solid documentation)

-control-flow logic checking (you'll find more bugs than you think with this and it encourages more defensive programming)

-transpiling down to support older browsers (babel does this too but it's nice to have it built in)

Edit: I forgot to go into the "cons" list here.

-there's some finagling you'll have to do with some of the more poorly-written npm packages that strap themselves onto globals

-there's a slight learning curve

-you'll require a build step (with es6 if you're targeting es6-only browsers you can deploy just static files, but most people use webpack/babel anyway for older browser support and other things webpack gives you like bundling/minification/etc)

> you'll require a build step

I'd like to note that this is done automatically in Visual Studio 2015 and on. You just save your .ts file and VS will create the .js file.

While IDE transforms can be handy when getting started with small projects, you cannot use them for automated builds (projects with multiple contributors, continuous integration). Any serious project using TS does indeed require a build step.

As much as I will fairly praise Visual Studio, thanks for pointing out this automatic generation feature

I'm not by nature keen on automatic behaviour, or files appearing wherever, and though I visited this story simply to check in on the state of a language I know less than I want about, I'm certain that I would want a proper build step even for tinkering, once I start in earnest. I've long been enthusiastic about TypeScript especially, but from a distance, unable to allocate time to take it seriously enough.

I think the state of js and environment is now at a point that, in my view at least, I should not begin the smallest project without a deep dive into the state of the language. I see things moving so fast, that - at least in my workplace where we've had teams stick together for years commonly (partnership!) - it would suck to find oneself misdirected by a aggressive assumption, or find oneself in a unloved cul - de - sac of dependencies.

Tl;dr js is IMO at a place where the pay off for deeply studying the state of the language, is substantial while risk of not deeply groking js are rising fast.

Personally, I think I shall better resort to getting a new shelf of good books, for my needs, but I do believe the risk reward is looking hairy for any casual users. (or hurried business management, in particular)

I'm a little surprised, given my understanding the impression I had of ts is the very broad aim is to reduce your error in code, (type safety only part of that) that VS will encourage casual / random deployments like this. I can't decide if it's a occasional convenience quite suited to weekend js ciders like me, or a omitted formality that I feel encourages poor or slack habits.

Funny thing is, I never once thought of firing up VS to write JavaScript before now. I have no need, but I'm just displaying my age when I note that visually my mind thinks of early Netscape view source spelunking and text editors, not a actual IDE and build system.

What keeps me, well into a fourth decade of programming, from using JavaScript I think is only the fact that I totally phase out at the state of the tool chain for js. My mind blanks. But there's so much to like, using js, that i hope it's not abandoned by time I get to really learning it. (forgive my humour, but my first real computing experience was on a Symbolics 3650, then spanking new. Last week wanting to show a friend what one looked like, I found kids veritably boarding them! (sorry for the kids part, but it's nuts I found such phrases creeping up on me, I'm lucky in looking less than my years, but when did I start saying things like "the kids are doing x"? I want to know what causes this, and if there's a cure!)

Edit: Typos, minor clarity

The killer feature of Typescript is being able to model data. Most serious bugs I see in JS applications are because somebody serializes something from JSON, passes it around, and somebody somewhere makes incorrect assumptions about the data. Being able to type my models, Redux state, config objects, etc is a huge boost to developer productivity and maintainability.

Isn't that rather more fundamentally a documentation failure? Or communication failure, if data producers are expected to signal protocols where you work. Else a formality oversight for the data consumer developer to not seek documents and check your specs?

True, it _results in a bug. But when bug count gets high, and I see a noticeable percent originating from slacking habits, I start prowling to find who's been pulling too much overtime or something family is tiring them out. Nine out of ten times, it's someone who needs only firm advice to look after themselves better. Where I work age skews much higher than SV norms, so young children and other delights (not /s at all) have notable impact on code quality.

Not really. There's intrinsic value in being able to type a variable name and see all it's properties without having to look up documentation -- especially if it's code you're not familiar with. One less thing you have to balance in your head.

Very good point.

I quite commonly get a wood<>trees occlusion, when I'm thinking through my own habits, to visualize the world. I've just made documentation such a important part of my working life that I am constantly thinking through that structure. It began with a prospective business partner trying to blackmail my company in part by withholding key metadata for a important deal. The deal that founded my company, in fact. I know I was scarred badly by that. And this was a important friends, ten years my senior, without whose advice I would have..i don't know what other path... So I made self documenting a whole schedule in the partnership. Forget living off a LP interest in retirement, if you pull a stunt like the one that nearly bankrupted us before we started. (unlimited liability! We are since a limited partnership, but the fact we were a general partnership actually saved our houses on that first deal. The customer CEO actually noticed our names as one does put them on the letter head. Suddenly calls were made, subsidiary directors were gotten at home to listen up... Our customer CEO sussed how much we had on the line. The world changed in a instant. Not a small customer the kind you think might cate, either, DAX30! Edit to say I doubt any but a German boss would spot a partnership firm by letter head. &co KG is a very common incorporation form, UK L.P. also permits a limited entity as gp. UK lp can be domiciled wherever you like, too. If anyone will be helped by any experience i might offer, just drop me a line, I believe some of our long observations could have genuine assistive value for starting ventures. Specifically for any non UK nationals still wanting a post Brexit presence at minimum exposure. Banking for these partnerships can be tricky, or you may simply be blanked by confused staff, but I've has good experience i can relate if you need to bank in the UK for a project. N.b. UK L.P.s are not taxed at the corporate level, only your personal income can be taxed. The potential for compounding gains when yours small and growing, is nothing to be sniffed at)

^ all of which is of course available in Flow as well (in case OP got the wrong idea.)

I have only superficial experience, but the biggest benefit of typescript over flow is the tooling. It is easy to setup, with transpiling, JSX, linting, webpack loader all bundled together, while with flow you have setup a lot of different components yourself, which may not interact well with each other.

Heard a talk about that a while ago. Here are the slides maybe you can get something from them. https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.ht...

Reply on news.ycombinator.com