Hacker News Reader

Comment by bluepnume | Hacker News Reader

I'm a huge Flow fan, and picked it over TypeScript because at the time I didn't like the idea of:

- Switching everything to .ts and .tsx files

- Switching a lot of tooling (TypeScript's built-in ES6 transpiler instead of Babel, tslint instead of eslint, etc.)

- At the time, TypeScript's types were nullable, Flow's were non-nullable, which makes a huge difference to me

- Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators)

That said, some of the errors from Flow can be incredibly confusing, and even with the latest versions I feel like there's improvement which needs to be made here. This (in my view) is the number one thing it needs to drive adoption.

View on HN

I went through a similar process and chose TS > Flow.

- Renaming to .ts and .tsx is nicer than adding comments, because it integrates better with tooling (compile all files that end with .ts) and it's easier to see at a glance what's ported

- You can always compile TS to ES2018 and run that through Babel, if you like. TSLint -> ESLint is indeed a change, though you can continue to use most of ESLint for TS [0]

- As a rule, TS is compile time only. There are a few exceptions, but that's almost always the case.

For me the advantages of TS are:

- Huge library of community written typings for JS libs

- Mapped types

- Full support for literal types

- Read only types

That said, I really like Flow's co/contravariance annotations, and the corresponding $Supertype and $Subtype functions. That, and nominal typing can be really convenient (coming to TS soon, hopefully).

[0] https://github.com/eslint/typescript-eslint-parser

> As a rule, TS is compile time only. There are a few exceptions

Sorry just for my information: which ones are those?

I'm pretty sure generators need a runtime component. TS supports them down to ES3. Async/await gets transformed to generators too afaik.

The typescript compiler is a type checker and a cross-JS-version transpiler in one. Runtime code introduced to support generators in lower ES versions isn't exactly the same as the type system needing a runtime component. It's more like "the Babel part" which is included in TS.

I personally don't think it's an attractive part of TS; it's confusing, and it's just duplicating efforts that Babel already does best. But that's just me.

> That, and nominal typing can be really convenient (coming to TS soon, hopefully).

I think you meant structural typing? TS was always nominally typed. I searched for a bit and it looks like TS also supports structural typing with explicit interfaces, and I think Flow tries to infer such types? I don't use either one, so I'm not sure about the details.

TS is structurally typed. You declare the fields you expect on a type or interface, and as long as an object has at least those fields, it will typecheck. Nominal typing would mean that you could declare type A and type B with identical fields, but if something is declared as A, it cannot be used in place of B.

TS has a strange workaround to get nominal typing for now:

https://basarat.gitbooks.io/typescript/docs/tips/nominalTypi...

That's interesting - I'm almost sure last time I checked (possibly a couple years back) TS used nominal typing. Do you know if this changed at some point, or is it just my memory being bad?

TypeScript has used structural typing since the beginning. Classes used to be nominal, but changed to structural (except for classes with private fields) at some point.

> Classes used to be nominal, but changed to structural

Ah, ok, makes sense. I think I was last looking at TS around version 1.1 or something like that. Thanks!

> Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators)

This is a huge part of why I tend to prefer Flow for my projects these days as well.

I really value the fact that Flow is just a thin layer of static type annotations you place on top of your spec-compliant JavaScript, and none of its features have any chance of introducing unexpected runtime behavior.

Also, I'd like to add that using Flow with Babel transpilation targeting a ES20xx preset largely guarantees that the source code you're writing is valid spec-compliant JavaScript that can run without transpilation one day (requiring only a dead-simple type-stripping transform using something like https://www.npmjs.com/package/babel-plugin-transform-flow-st... or https://github.com/flowtype/flow-remove-types), and I've had great success with simply dropping all/parts of the transpilation step as the features I use start to become supported in node/browsers/react-native/electron/runtime-polyfills/etc for apps where I don't plan on supporting browsers more than a few versions behind latest, which has been an absolute godsend for debugging in both development and production.

I highly encourage people to try it out on a project where they can afford to do the same (i.e. for packaged projects where you have control over the runtime environment like Electron or React Native, or for web projects where most of your users happen to be also web developers). It's really been a breath of fresh air after dealing with all sorts of subtle transpilation induced bugs/edge-cases.

To be clear, I'm not trying to bash TypeScript, because it's an awesome project, with top-class tooling that has attracted an amazing community around it. I just wanted to remind all the people mindlessly shouting "TypeScript has won" into their own silos, that Flow is also a great type system, that just happens to be designed with a fundamentally different set of trade-offs in mind. That alone doesn't make either system better or worse than the other, but it does mean there are use cases where Flow can excel over TypeScript and vice versa, and that you should carefully consider your project's needs and what characteristics you value in a type system before simply cargo-culting one or the other.

This is possible with Typescript too with Babel 7. See my comment here https://news.ycombinator.com/item?id=15236089

Thanks for bringing that to my attention!

That sounds super exciting. I'm definitely going to have to give that a shot once it's ready.

Flow's excellent React Native support has also been a large part of why I've mostly been working in Flow-land these days, so I'm glad to hear TypeScript will soon become a first-class citizen in that ecosystem as well.

EDIT: As a follow up question, please correct me if I'm misunderstanding anything, but from what I've gathered so far, I suspect that the new babel-preset-typescript can't quite do _just_ type-stripping can it? Since some features in TypeScript have runtime implications, those would still have to be transformed as opposed to simply stripped, correct? So it looks like that fundamental difference between TypeScript and Flow remains in tact, but it's certainly still a huge leap in usability to be able to adopt the Babel toolchain as a first-class way of building TypeScript projects. Huge props to the Babel and TypeScript teams for making that possible!

> I suspect that the new babel-preset-typescript can't quite do _just_ type-stripping can it? Since some features in TypeScript have runtime implications, those would still have to be transformed as opposed to simply stripped, correct?

I'm quite new to Typescript myself so I really don't know. At least I'm not aware of such features and don't think this Babel feature would make much sense if there were any?

EDIT: I think some of the runtime features are just TS doing ES6 to ES5 compiling. Such as "for of" loops, generators etc., but since those are just ES6 syntax they can be handled by other Babel plugins/presets or even by modern browsers directly.

The two most obvious examples I can think of off the top of my head are features like Enums and constructor param visibility settings. Both must be transformed to retain their runtime properties, and both don't exist in any ratified ES spec. Luckily enough they both also happen to have fairly straightforward mappings to their respective JS implementations, and once you know that they do introduce runtime behavior (and it's fairly easy to notice that they do), you can simply avoid them, so the practical impact of these more obvious cases can be limited.

More troubling cases do exist though. I vaguely remember once coming across some obscure runtime behavior for decorators where they attach runtime metadata that's supposedly used for type reflection, which is a runtime effect that's definitely not immediately obvious or intuitive. This and other potential obscure edge cases like it, some of which may exist in TypeScript today and some of which might be introduced in some future version, are part of what makes Flow's focus on providing trivially removable static typings on top of spec-compliant JavaScript so attractive to me (in addition to opening up the option of minimizing the surface area of your transpilation step or skipping transpilation altogether).

Thanks. Here's the documentation about the enum issue https://github.com/babel/babel/tree/master/packages/babel-pl...

I hope that in future Typescript would take the same approach as Flow and just focus on being a good type checker on top JS.

To be fair, one can also stick to .js files and use TS in checkJs mode, in which case it uses jsDoc comments to add types information, so there is no extra step to strip types.

The downside is that a few features don't have a jsDoc equivalent. But it would already catch most of the things you'd use a type checker for, without the hassle of going full Typescript: you could even completely remove typescript from the project and it would still work given they're just JS comments.

Right, that's a great point. If the set of features that aren't supported in the jsDoc equivalent are the same set of features that end up requiring runtime transforms, then I can picture this to be an excellent way to use TypeScript the same way I do with Flow (which also supports a comment-mode syntax, but it doesn't have as compelling a use case in Flow since the standard syntax doesn't require any transformations to begin with).

Reply on news.ycombinator.com