I am Lee Byron. Ask me anything.

Lee Byron is an Engineer at Facebook. He is currently working on React, GraphQL, Immutable.js, Mobile & JavaScript. Shoot any questions you want Lee to answer!


Thanks for having me here!

Ask a Question

76 discussions

How does Facebook use server side rendering? How many projects are using that? I tried it but my workmate thought it was too slow compared to normal template engines. What do you think?

First of all, yes. Facebook uses server-side rendering heavily. Probably about 90% of facebook.com was first rendered on the server. Much of Facebook is actually pretty static in your browser, only dynamic portions like comments and chat use React.

However, there are very few places where we're using React to render on the server, and this is mostly a decision based on our server environment (Hack) and the history of how Facebook was built. React itself was partly inspired by XHP (https://github.com/facebook/xhp-lib) which Marcel Laverdet built at Facebook in 2009 to componentize our UI.

XHP let us write small modular UI components with render functions and introduced a new XML-like syntax to PHP (hence the name). If this sounds similar to JSX and React, there should be no surprise. We already knew React's component model was a good idea from years of using XHP to do server-side rendering.

In terms of performance, it's true that constructing components has a modest overhead to simply concat-ing strings together, however this hasn't been a burden. Also, we've found that this is more than made up with our ability to leverage the better abstraction in numerous ways: better component libraries, easier maintenance, and even parallelizing data fetching with UI rendering (https://github.com/facebook/xhp-lib/pull/104)

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

What do you think about CSS Modules?

It seems to be that css modules are perfect for styling of react components. What is your opinion?

Thanks. Michael.

I actually haven't used the latest proposed versions of CSS Modules directly myself, but we use something really similar to it at Facebook. Tim Yung built Facebook's version of CSS Modules in 2012 to be used alongside XHP, and later with React.

One thing that we did differently at Facebook, is we disallowed importing CSS rules into any file other than the XHP/React component. That helped enforce that a component should expose the right API via it's props to be styled correctly and that other components couldn't import a rule in order to override it. That also meant that we never needed to add anything magical to JavaScript to "import" a CSS file, instead relied on a naming convention where Button.js would sit next to Button.css

The last benefit of modular CSS that we really liked was the ability to minify the class names themselves. When looking at the DOM in our development environment we see full class names like ".Button_ColorBlue" but in development we just see ".a5u". That helps on file size, and ensures no one can "guess" what the actual class names in the browser will be.

Reply to this…

I'm really excited about GraphQL, particularly its type system and introspection capabilities.

  • What do you see happening to GraphQL in the short/mid future? Any plans to extend the spec with new major features or is it mostly going to remain as it currently is?

  • What tools, other than GraphiQL, you imagine can be built on top of it? Is there anything Facebook uses internally? Are there any new tools being developed?

Me too! :)

The last year or so of the GraphQL spec has been about honing what we have, and making sure how GraphQL works is clear and that it can be implemented in many environments. In many ways, GraphQL works and should be considered nearly stable, but there are also a lot of opportunities for GraphQL in the mid-term future.

One of the things I'm most excited about is extending GraphQL from the single-request-single-result model to single-request-multiple-results. For example, to enable some information in a request to be delivered before the server starts preparing other information, or even to keep an open connection to subscribe to live-updating fields. Right now GraphQL doesn't have a great story for reactive applications, but we're already seeing that start to change. I think a lot of future focus will be around this kind of exploration.

As for tools, most of what we do at Facebook and what we hope to see in the community is leveraging introspection to automate the things you would usually do manually. GraphiQL was a pretty obvious one for us in the early days, and we're excited that we could release it. Automating documentation and illustrating what a good IDE should look like was important to us. We're now seeing some of the GraphiQL features being integrated into existing IDEs where you're actually writing your code. At Facebook, we rely a lot on automated code generation (e.g. https://github.com/facebook/remodel). Especially in our iOS and Android codebases, we have tools which generate parsers, models, caches and other data layer code based on our GraphQL queries. That helps us protect against under-fetching and maintain type safety on those platforms.

Reply to this…

What's your take on Falcor (from Netflix) and how it compares to GraphQL/Relay?

Falcor is also awesome. When the GraphQL team first heard about it, we met up with the team from Netflix and we swapped notes.

It was pretty exciting to us that Netflix saw very similar problems to be solved and even arrived at a similar looking solution, and that we had both been using our respective solutions in production for a few years. It was a sign to us both that we weren't crazy.

There are some important differences between the two though:

  • Falcor returns Observables, GraphQL just values. For how Netflix wanted to use Falcor, this makes a lot of sense for them. They make multiple requests and present data as it's ready, but it also means that the client developer has to work with the Observables directly. GraphQL is a request/response model, and returns back JSON, which is trivially easy to then use. Relay adds back in some of the dynamicism that Falcor presents while maintaining only using plain values.

  • Type system. GraphQL is defined in terms of a type system, and that's allowed us to built lots of interesting tools like GraphiQL, code generators, error detection, etc. Falcor is much more dynamic, which is valuable in its own right but limits the ability to do this kind of thing.

  • Network usage. GraphQL was originally designed for operating Facebook's news feed on low end devices on even lower end networks, so it goes to great lengths to allow you to declare everything you need in a single network request in order to minimize latency. Falcor, on the other hand, often performs multiple round trips to collect additional data. This is really just a tradeoff between the simplicity of the system and the control of the network. For Netflix, they also deal with very low end devices (e.g. Roku stick) but the assumption is the network will be good enough to stream video.

Reply to this…

Thanks for your time Lee.

With each major release in React, do you guys work on upgrading the components used in Facebook? If yes, how do you manage to do that considering such a huge codebase?

We do! In fact, we're not only updating to the latest version when it is released, we're usually using the master branch of React in production at Facebook.

Keeping this constraint means that no single change to React can break existing components. The team is usually really good about doing research in our codebase first to understand what might break given a change (we also have a lot of unit tests), and that's usually the origin of warning messages that are introduced in some versions of React. Breaking changes in React usually take two major revisions where they take only one in most libraries. First to introduce the warning, then to introduce the breaking change.

It also helps that most of the development in React is simplifying, and there haven't been many serious changes to its API since it was open sourced in 2012, so even with a really large codebase, there haven't been many opportunities where the team has needed to upgrade things.

For the few times when breaking changes are introduced, a member of the React team (often Ben Alpert) will take responsibility for making any relevant changes across our whole codebase. We're often using automated tools to help make this easier, like jscodeshift (https://github.com/facebook/jscodeshift).

Reply to this…

Load more responses