8 ms·
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 Flo
by vcarl 10y ago
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 :)
- spankalee 10y agoYou 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.
- dangoor 10y agoBut The TS parser will see object spread as a syntax error.
- dangoor 10y agoBut Flow still needs to be able to parse the JS. If it thinks your JS is invalid, you'all get an error.
- bsimpson 10y agoFlow 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.
- Touche 10y agoThe pipeline operating is super speculative. I would suggest not using it yet.
- bsimpson 10y agoIt'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.
- Touche 10y agoIt'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.