I am Christopher Chedeau. Ask me anything.
Open Source Contributor and Facebook Software Engineer in the Front-end team working on React, React Native, Prettier, Yoga, Nuclide and other important projects.
Ask Christopher Chedeau about:
- Building React Native Apps
- Working at Facebook
- Contributing to open source
- General advice
Thanks for all the questions! I hope the answers were useful and interesting!
The reality is that the cost of patent-related lawsuits is very real for Facebook. So real that it was put as a "risk factor" in the IPO document: "We are currently, and expect to be in the future, party to patent lawsuits and other intellectual property rights claims that are expensive and time consuming, and, if resolved adversely, could have a significant impact on our business, financial condition, or results of operations." ( https://www.sec.gov/Archives/edgar/data/1326801/000119312512034517/d287954ds1.htm )
If you want to get sense of the dollar values at stake, consider that Facebook bought patents for $550 millions of dollars in 2012 ( https://techcrunch.com/2012/04/23/aols-new-patent-owners-facebook-in-a-550m-deal-with-microsoft/ ), yes, you read it right, half a billion dollars!
React has had its share of controversies since the beginning and our strategy for dealing with them was to over-communicate and explain the reasoning. Unfortunately, we haven't done a good job on this one communication-wise.
The reason is that everything we say publicly on the subject can be used in court during one of those lawsuits. Given the crazy high stakes, the safest strategy is not to say anything. Even though you likely have hundreds of unanswered questions about it, I recommend reading through the three public posts we've published on the subject:
Thanks to the protection that this clause gives us, we have been able to open source so much of our core infrastructure at Facebook! As much as I believe that our open source work is impactful, it doesn't even remotely bring hundreds of millions of dollars to the table.
To conclude, is it an ideal solution? Not really. But like everything in software, it's all about finding the right set of tradeoffs. I've seen so many people empowered to build some really awesome things in response to us open sourcing React, Jest, GraphQL, React Native, Flow, Immutable, Draft, Yoga... that it may not have been the perfect set of tradeoffs, but it feels to me like a good one.
Share your programming knowledge and learn from the best developers on HashnodeGet started
Can you tell us about your journey to Front-end Engineer working on many great projects? How did you started? And in your opinion which are the must know concepts in Computer Science I as a web developer need to learn so that I can understand the principles and contribute to React?
When you join Facebook, you're not allocated to any team during the first month and a half, it's a period called "Bootcamp", where you have a mix of classes to teach you about all the internals of Facebook codebase and infrastructure and time to work on real problems. Once I cleared the first few small tasks assigned by my mentor, I looked at all of them and there was one created by someone named Pete Hunt that piqued my interested that looked along those lines: "We know where faces are in photos, it would be interesting to use this data to improve the tagging experience". And little did I know, I managed to ship a first version of the feature within the first month and it non trivially increased a core Facebook metric! When out of bootcamp, I then joined the photos team full time :)
I'm very familiar with all the tools that we are open sourcing and I think that they are awesome :)
For side projects though, I still love PHP and Apache. The developer experience is still unmatched today. You just winscp to your box, create a file vjeux.php and go to domain.com/vjeux.php and it just works. You don't need to add any dependencies, you don't need to maintain a server running, eating one of your port for every single side project (seriously, who thought it was a good idea...), don't need to use the command line, don't need to setup a transpilation/bundling pipeline, don't need to deal with CORS... You can send the url to someone and it's going to work and keeps working years in the future.
I'm really excited about what people over at Zeit are doing on that front. I feel like they come from the same background and they get how awesome it could be.
Facebook is in a very interesting position regarding React, React Native... because we have very few "apps" and largely operate (or at least try to) as monorepo. This means that we invest in the infrastructure for wiring up everything (linting, IDE integration, bunding, shipping...) once and everything at Facebook uses the same one. This is a stark contrast from the open source world where each project or sub project is a separate repo and you've got to setup everything from scratch.
We have another stance which is that we try to only open source what we use at scale, to make sure that it's actually good.
Those two things are directly conflicting with each others: we can't really open source and do a good job at the workflow that most people use outside of Facebook.
For React, the plan was to wait until the community figures out a canonical way to integrate it into their stack and them promote it out. Unfortunately it didn't happen and after 3 years we just went ahead and did it ourself with create-react-app.
For React Native, we're in a much better state for an unexpected reason: unlike with React where a lot of people integrated it with their existing codebase and infrastructure, with React Native, a lot of people started using it from scratch. So, the task of designing a streamlined experience was much easier and we've seen really polished things like expo, create-react-native-app and ignite coming out of it.
I'm super excited to see non-Facebook companies not only invested in using React Native but also to provide some core features. This way we can really get each piece of the stack being worked on by the people with the best knowledge.