11 ms·
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though
by tonyhb 8y ago
This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.
- Normal_gaussian 8y agoThis is certainly how I feel; there are large parts of my codebases that I don't think will convert well if I was to change, where we leveraged flow to great effect. However I certainly take the point that flow has been developer hostile. When we have had issues it has been impossible to get a response (here is a demo, is this a bug or in the pipeline?). Though flow is v0.91 and Typescript is 3.2, i don't know if i can really fault them that much? I don't trust TS, they are too much 'move fast and break things'.
- WorldMaker 8y agoTypescript has been moving fast, but they haven't broken that many things. The API and Language Server have changed obviously four times from a semver perspective, but in general the language itself has been extremely stable with great backwards compatibility, and most of the type system strictness additions are behind opt-in flags making upgrades usually as gentle as you prefer them to be (depending on your attitude to strict type checking). (I had projects that started with TS < 1.0 and they all still parse and compile today, albeit with tons of lint warnings, particularly to use a better module system than AMD with pre-ES2015 TS imports, and all sorts of new type strictness options to turn on to make them all the more type safe.)
- WorldMaker 8y agoThings are quite different from the first few years. Typescript has largely converged with the capabilities of Flow as a type system, though from its "different direction". It's not entirely ML-ish algebraic types, but it's a usefully fair approximation that has a lot of pragmatic tools to get the job done. Similarly too, the type inferencing engine isn't a "proper" ML-ish one, but it's gotten very good at what it does, again to the point where things are starting to feel a lot more similar to Flow's support than ever. Especially because Typescript is getting a huge workout as the inferencing engine in VSCode, Atom, VS Proper (sometimes), and increasingly more IDEs even for raw JS projects with little to no type information. Even if you don't believe in the old Unix adage that "worse is better", Typescript today isn't that demonstrably worse than Flow. Depending on your metrics, such as general availability of community-supported type information, Typescript in increasing ways better.
- noir_lord 8y agoAnders (and the people he works with) has a track record of producing useful pragmatic tools/languages that help developers develop going back about 3 decades. I've yet to find anything he's done/worked on that I don't like, one of my programming heroes actually.
- daveidol 8y agoI don't think that holds anymore. Have you used both Flow and Typescript recently? Speaking from experience: I can't imagine anyone doing so and concluding that Typescript is the "worse technology" at this point.
- tonyhb 8y agoNot recently. It's now on my TODO to plan a transition of our frontend projects to Typescript. Have been thinking about it since 2.9 when they finally introduced mapped types; before then we were using some of Flow's meta functionality to auto-type our reducers.
- 4di 8y agoI worked with Typescript for 2 years, then worked with Flow for 2 years and now I'm back on Typescript working for a big company. I agree that Flow had better capabilities around soundness. But the tooling around Typescript really made me jealous, specifically in VSCode. Near the end of working with Flow, Typescript was getting some cool capabilities like refactoring JSX for React apps. Nowadays I can easily say that Typescript is a far better experience than Flow. There are updates every two months, adding some neat features that you might find in other languages. Then you add in the power of surrounding tools and their ecosystems like TSLint and it really feels like a next-level coding experience where the tools start writing the mundane code for you, driven the core TS static analysis.
- wafflesraccoon 8y agoI'd agree with everything you've said. Flow isn't bad but after working with TypeScript I could never go back. You're spot on with the tooling and ecosystem.
- ggregoire 8y agoAlso, TypeScript has a roadmap and when you report a bug, the devs actually reply. Flow doesn't have any of that.
- fooey 8y agoand now TSLint is merging with ESLint so all that effort and rules duplication will be going away
- whatever_dude 8y ago> This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues Most of not all of the issues had with types have been solved. Flow had some major tooling/developer comfort issues from day one and none of those are solved. Not to mention a really closed development roadmap (understandable perhaps, but nonetheless bad). As a developer, I'm glad TypeScript won. I want more tool/compiler/language/etc makers to understand that the developer experience matters. If someone makes a tool that only works well under one very specific setup and ignores everyone else, that's just very limiting.
- danielnixon 8y agoThis[1] typechecks in Flow but not in TypeScript: /* @flow */ interface HasIdentityFunction { id<A>(a: A): A } class Example implements HasIdentityFunction { id<A>(a: A): number { return 42; } } var x: string = (new Example(): HasIdentityFunction).id("hello") [1] https://twitter.com/puffnfresh/status/1077072700609159168 https://twitter.com/puffnfresh/status/1077072700609159168