Hacker News Reader

Comment by dangoor | Hacker News Reader

As far as I've seen, it's really only Object spread (likely ES2017 feature) that's commonly used that is not yet supported by TypeScript. Microsoft has promised support for it in TS 2.1, and generally stays on top of ECMAScript proposals that have gained enough traction that they seem likely to ship.

View on HN

On the other hand, Flow is removed from the code transformation, so it doesn't have to bother with keeping up with the spec. That's a pretty strong point in Flow's favor in my opinion, single responsibility principle and all that :)

You can do that in TypeScript too: just target ES6, use all the features like spread/rest and async/await, then compile the result with Babel.

But The TS parser will see object spread as a syntax error.

But Flow still needs to be able to parse the JS. If it thinks your JS is invalid, you'all get an error.

Flow understands some TC39 proposals, if you use the right flags:

esproposal.class_instance_fields=enable

but it chokes on ones it doesn't understand. I tried using Flow and RxJS in the same codebase. RxJS makes heavy use of the pipeline operator:

stream::map(thing) vs map.call(stream, thing)

Flow will stop checking types as soon as it sees ::. Babel parses it, but Flow runs in parallel, so it needs to be able to walk the AST itself.

The pipeline operating is super speculative. I would suggest not using it yet.

It's still early, but it makes Rx code much easier to read. So long as you're comfortable using Babel for transpilation, it doesn't really matter whether or not it's TC39-approved.

It'll matter in 3 years when you have an app that's full of rejected ideas.

That's the problem I have with the Babel-everything mentality of a lot of developers, they don't realize that they are essentially created their own quasi-language that they'll have to support on their own.

Reply on news.ycombinator.com