Vacations with my wife and kids. I've been super fortunate to have been able to do so many trips in the past few years and visit awesome places :)

The best advice I ever got was from my wife when she said "is what you are doing is useful for Facebook or are you just playing around?". I feel like this sums up my view of Open Source really well. First and foremost, I want to work on things that are useful and impactful for the people who are paying the bills. Then, if it's more widely useful, then open source it and invest time making it successful outside. I feel like we've done a really good job so far navigating this, where we've spent 80% or more of the time providing value for Facebook with those projects and then with 20% make a thriving ecosystem around it that in turns benefits Facebook.

An interesting thing is happening is that as we try to solve harder and harder problems, we are finding ourselves wanting to change the programming language we're living within. We have a bunch of efforts at Facebook trying to do so: When I joined 5 years ago, we were already adding features by "transpiling" our code. We are part of TC39, the JavaScript standard committee, trying to bring new concepts to the language itself. We are investing a lot in Flow to add an incremental type system to JavaScript We're investing into bytecode representation and optimizations for React Native and finally are trying out using a completely different language that targets JavaScript: OCaml. Reason is an attempt at greatly improving the syntax, developer tooling and documentation to make it feel like a 2017 language instead of early 80s :p One of the big issue is that we don't have a crystal clear idea of what we actually want so exploring many avenues is a really good thing to do, and I'm so glad that Facebook is willing to dedicate so much efforts into those! I'm not super familiar with the rollout of Reason inside of Facebook, I know that Messenger.com is using it heavily and successfully and I wouldn't be surprised if there was a bunch more other things that are lower profile using it as well. You should ask this to the reason folks on discord, I'm sure they'd be able to give you a better answer.

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.

I haven't tried flutter yet myself but I've watched all their external presentations since they started the project and spent a lot of time on their mailing list. The super short take-over-the-world plan for React has always been in 2 steps: 1) Abstract away the underlying imperative UI representation so that most of the code you write is React. 2) Swap the underlying representation with something designed for React specifically. What Flutter attempts to do is 2) directly. Let's ditch the entire platform and recreate one from scratch. This is something that we've always wanted to do at some point in the future but we've always felt that it wasn't going to work because it was too much of a big-bang rewrite and there was no incremental adoption story. I really want them to succeed as the model they are using is a much better one IMO than most of the current imperative-based platforms we have today. As for our ambitions, I'm really happy that we're exploring it with React VR. This is essentially React with a backend that talks directly to OpenGL. This way we can remove all the middle mens and get absolutely awesome performance and developer productivity.

What drove me crazy is that for the longest time, people dismissed the fact that there were issues when using CSS at scale. The response was along the lines of "look, I'm using Sass and now everything is magically working great". What I wanted from that talk is to get people to admit that there were real issues and start working on solutions for them. On this front, I think it worked way better than anticipated! As for your original question, I honestly don't know if writing styles in JavaScript is the best thing to do and even that is a wide space, there are so many ways to do it. But people are trying a lot of different things and it's super exciting to see! PS: there's still is this accepted stance that setting styles inline from JavaScript is slower than using CSS. I can't find any reasonable argument why that would be the case. If you set the style directly to the element, it MUST be faster: the browser doesn't have to match that element against the thousand of CSS rules you have, doesn't have to invalidate cache when you add/remove rules or move elements around. But yet, I somehow can't convince people that my argument is reasonable and to get people to write benchmark about it / get browser vendors to actually make it faster if that's not the case already.

Ever since Go was released with gofmt, I've been fascinated by the idea of pretty printing the entire codebase. For three reasons: On a technical level, what are the algorithms to be able to do that and produce reasonable code On an impact level, it's going to avoid wasting so many people's time. See this section of the README for the rationale: https://github.com/prettier/prettier#why-prettier On a people level, I wanted to see if I could get good at the convincing game During the winter break, two people independently started working on a JS pretty printer: James Long on prettier and Pieter Vanderwerff using Reason and the flow infrastructure. I started being the cheerleader by setting them up with unit tests, sense of progress around how many nodes needed to be printed, telling them what looked bad when running through a real codebase so they could fix it... They both made a lot of progress but unfortunately had to get back to their "real job" at the end the vacation, and I didn't want for yet another effort to die, so I worked on it full time! As for everything meaningful, you've got to pitch what you want to your manager and the org so that you get support. The good thing is that a bunch of efforts to automatically format code as spinning up at Facebook for various languages (Python, Java, Hack...). So the vision is definitely starting to be shared across the company :)

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.

My journey started when I was still at school and during a weekend I wrote a prototype called JSPP ( http://blog.vjeux.com/2011/javascript/jspp-morph-cpp-into-javascript.html ), a way to exploit C++0x and macros in order to write C++ code that looks and execute in the same way as JavaScript. In practice it is useless but it got to Hacker News and someone from Facebook reached out to me to figure out if I was interested in joining the company. At first I thought it was a prank, but I'm so glad it wasn't! After a few phone interviews, they bought me a plane ticket to California and booked an awesome hotel so that I could do a day of onsite interviews. Even though most people seem to hate interviews, I actually very enjoyed the process, it's not often that you get to be intensively challenged for an entire day by really good people. I got an offer and started 6 months later when I finished school. 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 :)

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: https://code.facebook.com/posts/1639473982937255/updating-our-open-source-patent-grant/ https://code.facebook.com/pages/850928938376556 https://code.facebook.com/posts/112130496157735/explaining-react-s-license/ 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.