Facebook's own Flow adoption? #7365
Comments
|
Yeah, big +1 on this. I just finished an upgrade in a product at our company to beyond Some more vision on Flow future would be 💯 right now. |
|
related discussion here about desiring a public roadmap or vision for the future: #6833 |
|
Another recent example I encountered is from the React Native website, the Getting Started guide begins by recommending to build with Expo (so not an official Facebook product, but heavily endorsed), which also decided to migrate to TS (expo/expo#2164) and is now even actively recommending users against using Flow in their own codebases (expo/expo#3069). So the official onboarding for React Native has now become to use TypeScript. Which is strange considering Facebook does seem to be putting a lot of effort into further improving RN's Flow typings (facebook/react-native#22100), and doesn't even officially export any TS typedefs for RN. |
|
This is very interesting topic! The latest news without comments from FB affects the community. Uncertainty easily eats the motivation and makes you think wether it is worth the effort to invest time in Flow community. For example, there are plans to migrate flow-typed to Lerna & publishing the libdefs in NPM. We probably do it nevertheless, but knowing Facebooks commitment would be highly motivating. |
|
I'm on the Flow team. These are my own views, so don't take this to represent FB or the Flow team in general. @avikchaudhuri is planning some communication around the Flow team's recent work and our plans in the next week or so. Personally, I believe that Flow's focus on soundness (an explicit non-goal for TypeScript) means that there will continue to be a place for it. Of course, we have some holes in our type system but we continue to work to fix them. Soundness is especially important for large projects, or projects which have a particularly high quality bar. Facebook's main JS codebases continue to use Flow, and I don't see any evidence that that will change. I wouldn't read too much into one relatively small, isolated project switching over. Different projects have different needs, and that's fine. I think we have an exciting year ahead. For a long time, we have been hardly able to keep up with the needs of Facebook, and that has led us to neglect the open source community. However, the team has grown significantly in the last six months or so, and we are close to wrapping up several important performance projects. I'm optimistic that we will be able to find the time to engage more with you all in the future. I'm going to close this because I think I have answered your question. Feel free to reopen or just reply if you need additional clarification. |
|
@nmote are there any plans to publish a roadmap of some kind? It would be super helpful if people know what's a priority for the team. |
|
@satya164 yes |
|
Thanks for your response @nmote , it's really encouraging to hear that the Flow team has grown, and that you're optimistic about being able to engage more with Flow users outside of Facebook. There have been some great features landing in Flow the past year, so definitely excited to see what's coming in 2019.
It might be worth this being communicated a bit more, as the general impression in all the discussion threads I saw over Jest's migration was "the writing's on the wall, Facebook is making an official move away from Flow", with no one stepping in to say otherwise. Jest is under the FB org, presumably used internally throughout FB, and the type of project you'd expect to strive for soundness (a test framework)... so the nuance that it's "relatively small and isolated" wouldn't be particularly obvious to people outside of FB. The announcement just came across as pretty bad PR for Flow, and ironically not from a competitor or anything, but from another FB project... |
|
Again, speaking just for myself, not for the rest of the team and the company. I don't know what went into the Jest decision, but from a look at the recent history of the repository it appears that maintenance has been turned over to someone who does not appear to be an FB employee. Absent something like malicious or incompetent behavior, I believe that active maintainers should have authority over their project, regardless of what org it is under. I don't think it would be right for Facebook to veto their technical decisions for basically political purposes. I agree that it looks bad but again, I wouldn't read too much into it. I'll see if @avikchaudhuri can address this point as well in his more official roadmap post. |
Ironically enough, testing is more about completeness than about soundness (as pointed out by the Flow documentation). Maybe this migration from Jest is only fitting, after all ! Joke aside, it's great to read that the Flow team just got bigger and plans to interact more with the community. Looking forward to it ! |
|
Thanks for starting that thread @jamesisaac, and thanks for the replies @nmote @jbrown215. Indeed it's a bit of a rough period for Flow users currently. Although I tend not to follow trends and always take announces and moves with a grain of salt. There was a worrying change as well with the abandon of Nuclide. What I try to point is we need to consider the whole ecosystem as well, because that's our daily routine: linters, compilers support and responsiveness (Babel, babel-eslint, react-docgen, ...). |
|
@pascalduez Guys moved their forces into better flow lsp support so any editor with lsp could seamlessly integrate flow. I guess VSCode is the first in the list of editors now. There is also coming builtin lsp support in neovim (and good enough plugin). I think this is the right direction. |
|
This is correct, we are going all-in on the LSP. It provides the best user experience and is quickly becoming a standard across editors. Unfortunately I don't have a good answer for how to continue using Atom with Flow, but https://github.com/atom/atom-languageclient might be a good start. I haven't tried it but the main contributor used to be on the Atom core team. Hopefully the Flow community can step up and fill in any remaining glue code needed between Flow and Atom. |
not trying to poor gasoline in the fire, but it seems another Facebook project is migrating as well: yarnpkg/yarn#6953 |
|
Please note that Yarn is a community project before anything else (as evidenced by it being its own Github org). I'm the only Facebook engineer also active member of the core team 🙂 Also note that the switch wasn't prompted by any deficiency in Flow - we (as in, the Yarn org) simply try to shake things up in order to attract contributors. Maybe it'll work, maybe it won't, but this doesn't reflect in any way Facebook's investment in Flow. |
|
Now tell this to every person on twitter who wrote that flow is dead. There are a lot if such tweets. |
|
I'm really sorry to say that, but personally, for me Facebook has become #1 disappointment of 2018. Good tool lost a war to the bad tool. It's not enough to have the best engineers, software in our days is a community around it. Facebook just threw away their community and it was the main reason why Flow lost to TS. You lost Nuclide, then quite well-known tools dropped Flow in favor of TS, what will be next? Maybe we should try ReasonML? You know what? How we could trust FB after that? It can become dangerous to use FB tools, who knows, maybe I can start to use ReasonML today, but tomorrow it will be moved to the facebook-archive organization? How people can believe in FB tools and contribute to them? All development going behind closed doors, so no one can be sure that their contribution to "open source" will be thrown away. People will start to afraid of using all FB tools, not just flow. Of course, everyone will continue to use React, but if we speak about new and experimental technologies - less and less amount of people will be eager to contribute them and adapt. It will be harmful not only to Flow but to all FB projects more or less. Just imagine for a second - web developers trust Microsoft more than Facebook, a few years ago MS products (IE) was the pain in the ass, everyone remembers that, but still people trust MS more than FB. Isn't it a strong signal enough? It's just unbelievable - it a beginning of 2019 and there are no good type systems for js.
Flow was a really promising thing, and I still think that it was the best attempt ever to "fix" javascript. But it doesn't really matter if no one will use it. My current company will likely migrate to TS soon as well, so I will be forced to switch to TS as well. You can say lots of times that Flow is not dead and will grow, but who will read that if you write about that in GitHub issues? Where are Medium posts? Tweets? Public RFC? Q-and-A sessions in Reactiflux? Just anything? You told community month ago that you will share FB plans about Flow. In the meantime Jest and Yarn switched to TS. A lot of developers read about that on Twitter, Reddit, other places. And nothing from Flow. People read news about everyone moving to TS and no news from the Flow team. Just a few answers in the middle of one GitHub issue. Honestly, it would be better for you to hire not only developers but some people who will work with the community and create such posts, tweets, articles. You promised us to work on your mistakes in 2019, but close to the end of the first month we can see only labels for issues (thx @jbrown215 for at least such thing), but that's it. You can say that there were holidays and vacations, but in the meantime, other projects were capable to start TS adoption and writing about that across the internet. You can say about your other problems, about internal FB problems with performance, about the focus on internal needs, about high workload and inability to spend more time on public activity etc, but it won't matter at all. No one will read this issue. 36 likes for main post and 28 for the answer - that's all your community. And more of that, it will be still just words. You can promise a lot of stuff (which again no one will know about because there are no blog posts and tweets about that), but other projects will action. And for people actions + public discussions of these topics are much more important than words. To be honest, I don't really know if it's not too late to do something and how many efforts FB will need to get back the attention of the community to Flow - probably it will be too expensive. I don't even know if anyone is interested in reading all that whining - there is no public goals and roadmap so I don't really know if FB interested in making Flow widely adopt outside of internal FB codebase. Maybe it's just a tool for internal use and it's enough to keep it alive, but no one interested in promoting it outside. I just really upset that I'm lost good tool and will be forced to use bad tools. Of course, I will use Flow for pet projects until it will be moved to facebook-archive, but soon it will be harder to find a job position with Flow than job position with Haskell. I just have no choice but to use the bad tool instead of good one in daily coding. I won't convince anyone in any company to use Flow, while everyone else switches from Flow to TS. And again to be clear: I'm not the guy "I've struggled with Flow too much, so I've tried TS and love it, bye-bye Flow". Just vise versa - I've tried TS and it just doesn't work - it can't catch any errors and it's not even close to type safety. I really wanna continue to use Flow. But I can't, I just can't. |
|
All I can really say is that this is fair criticism, and I'm doing everything I can to improve things. It looks like there is growing organizational support for increasing the time we spend doing things like merging pull requests and triaging issues. @avikchaudhuri is still working on finishing a plan for the rest of 2019, at which point he will publish it, probably on Medium. We'll also most likely increase our presence on other platforms, like Twitter or Slack. But it takes time to change habits, and I understand if you are out of patience waiting for us on this. I'm sorry to have disappointed you. |
|
I really appreciate that you understood the issue, but I afraid that it can be too late. "at which point he will", "most likely" is not something that can stop that snowball effect from Yarn and Jest migration. It could help half a year ago, before all that changes, but right now average developer will move just because other well-known tools and companies move. The community will continue to decrease even after publishing a roadmap. The roadmap is nothing compared to Yarn and Jest. In the best case it will be "ok, I'm migrating right now because TS is much better, but maybe someday I'll give another chance to Flow if they will really work on their problems". Snowball effect is really underestimated, your tweets and articles could be lost in the middle of the hype train around "Typescript taking over the Facebook" topic. It already should be something much more serious than a bunch of tweets/articles. And time is really critical resource here - article today will give much more attention than article tomorrow. And an article in 2 months will be just useless, just because everyone will forget about flow existence. You could think "we need one more week" to polish everything - but in that week few more major libraries will migrate to TS and positive effect from the article will be already neglected by the fact that everyone moves. It's not anymore just about flow internal organization problems - it's snowball effect which is quite hard to stop, no matter how hard you will improve Flow and collaboration with the community. It's not even like starting from scratch - it's starting from the level below zero, because lots of developers remember hard times with Flow and will afraid to give it second chance. I could imagine lots of tweets around upcoming changes "when FB will stop beating the dead horse and migrate React to Typescript? everyone will be happy". It will be much harder to deal with it than anyone expects. P.S.: @nmote, you never disappointed me (and other FB devs), I like Flow as a tool, and compared to TS it's much much better. The thing which disappointed me - management of all that stuff. Flow could be in much better shape right now if the community would have more attention, if there will be public roadmaps, RFC, blog posts etc, but it's not a developers fault. Development of Flow was behind closed doors without transparency and I doubt that it was pure developers decision. I hope FB management learned that lesson and understood that it's just not enough to hire bunch of good developers and create public open source project. It's totally enough for internal projects, but when you have competitors from other companies and wanna take over the community - you need to invest in it LOTS of time and money. It can't be done by developers alone. It should be a clear policy on a company level. |
|
What's happening with Flow is so regretful. It is so hard to evangelize Flow in commercial environments. Despite all its benefits, how can you promote something that still partially broken on some platforms (hello Windows) and broken completely for almost half a year in Windows version of the VS Code? We all understand that Facebook and Flow teams own nothing to anyone. Still, it is sad to see how extremely bad tool taking on the market. Let's be honest — it will be nearly impossible to battle TypeScript those days without some good efforts.
But I'm still with you, guys. The Force should be on your side. |
|
To be more specific, at least a few things should be done to start moving:
That should make Flow at least a viable option. |
|
I think one could make a strong case for decentralizing flow typedefs. There's a tradeoff to be made between typedef quality (a centrally maintained flow-typed repository) vs. typedef availability (types maintained by numerous 3rd parties). However in my opinion, the community has already voted in favor of availability by adopting typescript. The flow-typed tool could be made to facilitate importing typedefs from other repositories. Authors would be incentivized to create typedefs because they would receive the lion share of the praise for doing so. Likewise, they would not be disincentivized from creating typedefs because they would not have to wait for Github gatekeepers to review and possibly reject their pull request. |
|
@ArmorDarks flow-typed is getting better: flow-typed/flow-typed#3083 But it feels like that project gets little to no support from FB. The community has to keep even Redux's types up-to-date themselves. |
|
One way to help library authors deliver definitions with there packages could be to revive Combined with |
|
@pascalduez flow-gen-type replacement is coming soon. They already work on it for a while. |
|
I've probably been too specific about what to do with I rather wanted to highlight that current way to publish library typings is so painful that only because of that many developers even didn't consider adding Flow types. Just imagine all the steps maintainers have to go those days to publish any library and throw on top of that the need to publish types to the 3rd-party repository and wait for them to be approved. Ignoring the fact that it is tons of hassle by its own to keep in sync something you don't own directly, what should happen with the release in that time? Be released without types? Put on hold release only because of the PR? Since it makes Flow grow problematic, it is one of the major issues which should be addressed. That was the point. |
|
@ArmorDarks and others, if you have ideas on how to make flow-typed better, feel free to open issues in the repo! We are happy to hear and consider any improvement ideas. Currently we are researching the option to publish libdefs in NPM. Also note that any support from community is highly appreciated since maintainers have very limited amount of time to put effort on the project. |
|
Thanks everyone for all the input. You've all made some good points. Regarding flow-typed, I agree that discussions about specifics should be taken elsewhere. The Flow team is very grateful to the folks maintaining it. We are planning to provide a replacement for |
|
Here's a Medium post from @avikchaudhuri with some more info: https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f |
|
Just want to cross-post my comment here: #6833 (comment) In summary: there are many issues around monorepos and node_modules that prevent people from being able to use Flow (without tons of brittle hacks), or force Flow to read all the files in your node_modules directory. I have moved to TypeScript this week because I simply could not get Flow to work with my codebase. I tried for like 2 years to get the right config but just couldn't get it to work. The changes needed are tiny config options which lots of community support that were ignored by the Flow team. Please fix the basics first! |
|
We're considering our options around |
This comment has been minimized.
This comment has been minimized.
|
It's not about whether typescript is better or flow is better. For somebody typescripts fits better and for other person flow does. For my purposes flow suits me better because it gives me more freedom, it doesn't contain some architecture limitations like other competitive language type systems do. There has been some unfortunate events like archiving nuclide, because default type system in IDE does the conversion. Yes there is vscode alternative but it defaults to typescript, and require some setup. Also author of extension migrated to typescript ;). So what we need to do is better support for flow. We can't to expect that facebook team does everything. What i read i assume they prioritise they internal projects. If we want to spread flow more, then I think:
So instead of complaining let's do something. |
|
@rostislav-simonik, you can generate Flow from TypeScript with flowgen, but it is not perfect, I already converted all of DefinitelyTyped https://github.com/goodmind/FlowDefinitelyTyped/tree/master/flow-types/types, but there is still many errors in automatic conversion I believe @nmote explores |
Sounds great. Could you provide a link to this POC in this topic when it's ready ?
This is by far my favorite method, though it might be complicated to setup in non-flow projects. |
Great. Could you @goodmind please elaborate more (probably would be better to start, find another issue, due it's not related to this topic). My question is what kind of errors you are referencing to. Thanks. |
@debel27 np, I'll create issue on flow-typed and will comment and reference it from here then. |
|
@rostislav-simonik maybe you can join Flow Discord, I don't think it is suited for issues |
|
@rostislav-simonik there is some work to push libdefs to NPM: flow-typed/flow-typed#3083 Unfortunately progressing very slowly due to other priorities. |
|
@villesau Thanks for comment, yes I know. I've read your issue before. I wanna to try poc how to do it manually but will use your proposal so packages will look like flow-typed created them, so we won't be blocked until v3 of flow-typed will be finished. I understand i'm also occupied by other priorities, so maybe incremental approach would be better. |
|
@rostislav-simonik nice to see that there is enthusiasm to improve the situation with libdefs! I'm curious to see how the POC turns out. I like the approach you are proposing, but as with wikis, there are risks which i'm uncertain about. That said, people who review the libdefs are by no means better in their job than anyone else - just a bit more practiced about libdefs in general. No-one knows the nuances of all the different libdefs so it's nearly impossible to guarantee the uniform quality of them. @orta I think flowtype would be perfect home for flowgen if you are considering moving. But flow-typed has a benefit that no need to sign FB CLA or go trough FB process when adding or removing maintainers. This was the reason flow-typed was moved into it's own organisation from flowtype back in the days. (cc. @gantoine ) |
|
It feels like flow's been steadily getting better. There were a couple of issues that were bugging me a couple of months ago (inference of basic things like Array.prototype.map and variance of literal assignments) that been resolved. One thing that always catches me off-guard is how many stale PRs there are in this repo. I know there are probably bigger fish to fry, but closing old PRs that are never going to get merged wouldn't take that long and would signal that someone's looking at things. Also, I think the CONTRIBUTING.md could be expanded to talk about what kinds of changes the flow team is looking for, coding standards, maybe a high-level overview of how flow's type-checker works. |
|
@kevinbarabash there was ton of PRs closed, if you filter by You can find high-level overview of typechecker in wiki |
and others
(Apologies if this isn't appropriate usage of the issue tracker, feel free to close if so.)
Jest (another Facebook project) has recently announced they're planning on migrating their codebase from Flow to TypeScript: jestjs/jest#7554
Quite surprised to see that decision go through, as I would have expected Facebook to just veto it for the obvious reason of internal cohesion/support between its own projects.
I'm personally more of a fan of Flow's approach of favouring correctness. A lot of my confidence in continuing to use Flow in my projects is that it's backed by Facebook's usage for its own projects (React, RN, Relay, Metro etc). But given that there's seemingly no opposition to a FB project, not even just being started in TS but being actively rewritten off of Flow, it brings this view into question. And of course, the linked issue is now being paraded all over HN, Reddit, etc, raising further FUD against Flow.
Is there any chance someone on the Facebook team could outline the company's long term plan for type system usage? Is Jest somehow an exception, and React/RN/Facebook's own internal codebases etc are firmly committed as Flow projects? Or is Facebook internally beginning to consider migrating away? From what I understand, every change to Flow's codebase has to be approved by someone employed by Facebook, so having an idea of how much attention FB will be directing towards Flow seems fairy crucial to understanding its long term prospects.
And I guess a further question is whether Flow is planning on prioritising the main issues people keep bringing up when discussing reasons to migrate away (support for 3rd party type definitions, stability of the type checker).
The text was updated successfully, but these errors were encountered: