Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

If you want runtime assertions with flow you can use flow-runtime [0].

Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript.

I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that.

[0] https://codemix.github.io/flow-runtime/#/

[1] https://github.com/babel/babylon/pull/523#issuecomment-31172...

View on HN

Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0

I was wondering does this make it possible to use proposals which have support in babel but not yet in typescript (e.g. do expression) when writing typescript?

At this point, it make senses for someone to write a TypeScript definition to Flow definition converter. Given how similar the languages are, I feel like you might even get away with using hacky Regex-based transformation instead of using ASTs for a lot of libraries.

I never did understand why Facebook and Microsoft ended up competing on this front.

> I never did understand why Facebook and Microsoft ended up competing on this front.

They ended up competing, but they did not start competing. The projects were started in isolation from each other. The fact that they are written in different languages (Flow: OCaml, TS: TS) makes it hard to merge efforts.

Ah, useful things to know about!

flow-typed does exist, so that's something. https://github.com/flowtype/flow-typed.

Between Flow and Typescript, looks like the latter has all the momentum. But I see one way in which Flow could become relevant again: by becoming 100% compatible with plain JS.

I would love to have type checking, but I'm weary of solutions that aren't really JS, and could fall out of favor or lack good support in the future. I'm pretty sure I'm not the only one.

But Flow type annotations don't really need an incompatible syntax AFAIK; they could just use comments. This way, we wouldn't need to worry about the future of Flow. If the projects dies off or becomes redundant, we're just left with some useful comments - no need to rewrite or transpile our code to native JS.

PS I found an existing project which does this [1], but it requires an additional step and it isn't officially supported. It looks incredibly easy to make Flow work directly with pure JS with comments...

[1] https://github.com/Kegsay/flow-jsdoc

The big thing I liked about Flow over TypeScript was the more accurate type checking. 2.4 looks like it has finally fixed that.

TypeScript can use JSdoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...

Thanks, but from a bit of research it's not clear to me: does this mean that it's possible to use TypeScript to type-check javascript files which include these annotations, without using .ts at all?

Yes, by using --allowJS and --checkJS switches (can also be set in tsconfig.json).

Thanks a lot - will try this!

Sorry but what is the use case for Babel + TS? I thought you use either Babel or TS but not both together.

Babel can now parse TypeScript source and turn it into an AST. It doesn't check types at this point.

You can use Babel with TS. For example, for JSX you can tell TS to "preserve" the JSX, which means you can tell babel or some other compiler take care of that transformation[1]. You can also use babel with typescript to use the babel presets for stage-[0-4] plugins. You can use the webpack TS loader, awesome-typescript-loader, to work with babel[2].

[1] https://www.typescriptlang.org/docs/handbook/jsx.html [2] https://github.com/s-panferov/awesome-typescript-loader

One case I ran into: using css-loader/style-loader for my css. TS doesn't understand importing css files, so that's where Babel comes in.

In the end i decided to stick to 'old-fashioned' SCSS with an npm script; the downsides of adding Babel to my stack weren't worth the upsides of css modules. Difficult decision to make though.

I guess what I'm saying is that while there is a use case, so far it's been worth it to just stick to TS without Babel, much as I wish it'd be different.

You could use the webpack (which you might be using already) css loader and declare the css file as any.

Support for DefinitelyTyped is what I really appreciate about Kotlin-to-JS.

What has your experience with kotlin and js been? Kotlin appeals to me a lot more than typescript and seems more practical than reasonml.

No more experience than reading the docs and watching an old talk from Andrey Breslav [1] where he explains how a DSL for HTML generation could work in Kotlin.

I like what I see and look forward to experimenting with it once I have more free-time (currently in grad-school taking summer courses). Kotlin as a language is really compelling, so I've tried to at least stay informed about it.

[1] https://youtu.be/OSBNkqy0UAI

Down-voted because research into language features is useless, I suppose?

TypeScript's IRC channel on Freenode is an amazing, supportive place, too. In sharp contrast to #gonuts, which is a cesspool.

Reply on news.ycombinator.com