A lot of talk has been given around React Fiber since it was first announced last year. And even five months later, there are still a lot of questions about it. This article seeks to answer one of them: What question does Fiber answer when it comes to rendering in ReactOr, in other words, what problem does React Fiber solve?

Author’s note: Unlike most of my other articles, this one benefits from some understanding of Javascript, as well as familiarity with ReactJS.  Stephen Grider‘s Modern React with Redux is my personal favorite course for learning this topic, and the one I recommend to most people. I should also mention that, while this article will focus on the web version of the framework, the core concepts can be applied to React Native as well.

React Fiber is an ongoing reimplementation of React’s core algorithm. It is the culmination of over two years of research by the React team.

This is a quote from Geoffrey DhuyvettersWhat is React Fiber and How can I try it out today? Which offers some pretty good guidance towards mastering this new technology, and is definitely worth a read.

But more importantly, this definition tells us two things:

  1. Fiber has been in development for half of React’s open source lifetime.
  2. Fiber is going to change React’s core algorithm.

What is it actually changing though? In very simple terms: Fiber seeks to change the way in which React renders our applications. But, before we can tackle how it will be doing that, we need to understand some core concepts that it aims to improve upon:

Prologue for React Fiber

Facebook has actually shared a little bit of the story as to why React was developed.

While they don’t really go into specifics of when it was conceived or what they were working on when it happened; it does allow us to get a general idea of the reasons for its conception: React was invented as an alternative to manual DOM manipulation.

And it achieves its purpose through the use of a few core concepts:

  • The virtual DOM.
  • Updating.
  • And Reconciliation

The virtual DOM

The virtual DOM it is an object-based representation of how the DOM should look like. It’s composed of React Elements, which are basically object representations of both HTML Elements and React Components.

These elements are the answer to the question: Who do we render in our application? (awkwardly phrased, I know.)

In order to help you better picture this concept, let’s look at a single element:

    type: 'button', //The main element, an html button
    props: {  //The properties the element has
        className: 'button-red',  //Keyword 'class' is reserved
        children: { //Nested HTML (or React) elements
            type: 'span',  //The nested element, a span
            props: {
                children: 'I am just text, so I don't have a type'

As we can see: It’s just an object. An object that represents a full DOM Node starting from a button, mind you; but still an object, nevertheless. And that’s all the Virtual DOM really is: A giant object made of objects that represents your DOM tree.

This object also tells us where to render everything in our application.

Whenever React detects that there’s a difference between this object and the actual HTML in our page, it draws or renders the application again. This ensures that they stay up to date with each other.


Now we know what the Virtual DOM is: a map of sorts that React uses to represent your application. This map, however, is very different from a map that you would have in real life.

While the earth takes thousands of years to change its geography, outside of human interaction; the type of application that React was originally conceived for is one that is constantly changing.

This means that we also need to be constantly re-drawing, or updating, our map to make sure it matches the actual geography of our application.

React has a concept of one way data flow which means, in layman terms, that our data can constantly travel down the objects in our Virtual DOM, and become a part of its structure.

This data can become the text written inside a span, or the class you add to a div. It can also become functions that our app can trigger in response to a user’s interaction.

Having our data become a part of our application structure means that: changes in our data can change the way our Virtual DOM looks; which will cause React to render our application again so it matches the new map.

This is what we refer to as an update.


So, we have a map for our application, and we also know that it is constantly changing along with our app. What we don’t know yet is how to re-draw it in an efficient and (ugh…) agile way.

In a very small application, the solution is simple enough: Take the whole Virtual DOM object and use it to draw actual HTML elements on our page, if something changes, render everything again.

But it’s easy to see that this idea won’t scale well to huge applications, despite how fast our re-drawings skills may be, if we try to render everything: each new element will make the rendering take longer.

We need a game plan. And that is where the term Reconciliation comes in.

Again, in the simplest terms I can come up with: Reconciliation is the process React uses to interpret the Virtual DOM and decide how to Update it. And to achieve this process, Reconciliation has several rules as to how it chooses to update the virtual DOM which it calls the diffing algorithm.

I really recommend reading Facebook’s own explanation on Reconciliation and diffing but, just to give you a general idea:

  • Redrawing the whole map would be very expensive in time and resources.
  • We instead make some assumptions as to what really needs to be updated.
    • These assumptions basically refer to whatever changed in our data.
  • Instead of redrawing the whole map, we reuse most of it.
  • That way we only have to make (ideally) minor changes, speeding up the process.

What our new game plan does is make it easier to render our app, e.g: only the className of our element changed, so we don’t need to render it again, we just have to change that property.

For the most part, this game plan (Reconciliation and Diffing) does a really good job at choosing how (in what way) and why (under which circumstances) we render our application.

And everything seems runs smoothly… Unless we get a huge chunk of data flowing down our application at once; specially if it’s going to vastly different places. Then we’re going to start running into some problems.

Because you see, for all the good parts that our strategy has, what it doesn’t have is patience: It will start re-drawing as soon as something changes in our map.

This means that, given enough differences, we could even be updating our entire app at once. Which, as we already mentioned, is very expensive and can lead to high latency in our applications, as well as some performance issues.

Still, for a good amount of time, the question of When do we render our application? Had a pretty straightforward answer: As soon as we can. And eventually the world realized that it really wasn’t the best one.

That’s when React Fiber came into play.

Enter React Fiber.

React just gets better with age and, going into the next step of its life, it has learned an important lesson that usually takes the best of us years to master: patience.

While React’s traditional way was to update as soon as the data became available, Fiber offers a new world of possibilities:

  • Pause a certain updating process, and also resume it at a later time.
  • Decide that some updates to our application map have a higher priority than others, and should be taken care of first.
  • Re-use the results of previous mapping updates.
  • Cancel updates, if it identifies a reason to do so.

Having access to these options when updating forms the concept of scheduling. And achieving this behavior is Fiber’s main concern.

Additionally, being able to manage the timing and condition of any given update has many desirable side-effects:

  • You can Chunk updates, reducing the overall latency (lag) of your application. This concept is what Fiber refers to as incremental rendering.
  • With smoother running pages come smoother animations (naturally.)
  • More responsive interactions, including gestures.

While this article won’t go into detail about how Fiber operates, I suggest you check out Andrew Clark‘s React Fiber Architecture if you want a more in-depth look at the specifics of how Fiber approaches the concept of Scheduling, along with answers to questions like: What is a Fiber? and How is a Fiber Structured?

The question React Fiber is here to answer.

While we may have answers to what do we render? (elements), where do we render them? (virtual DOM),  how and why we render them (Reconciliation and Diffing); React developers have always wished we had a way to figure out and decide when to render our application updates.

And that is precisely the question that Fiber is here to answer.


My name’s Orlando Paredes Hamsho. I’m a 25-year-old Web Developer living (mostly) in Guadalajara, Mexico; albeit I intend to move pretty soon. Apparently, I also run a blog now, and have been doing so for a while.

Write A Comment