DEV Community

Cover image for How I Currently Understand Rendering in React (My Improved Mental Model)
Usama
Usama

Posted on

How I Currently Understand Rendering in React (My Improved Mental Model)

I’m still learning React, but I feel my understanding of rendering is getting better with time.
This blog is my attempt to explain React rendering the way I understand it right now, in simple words.

I’m not trying to sound perfect I’m explaining this as a learner.


Components and Component Instances

First of all, we create a React component.

A component is basically a JavaScript function.
By itself, it has no effect on the browser screen.
Nothing is visible just by defining a component.

When we use that component in JSX, React creates a component instance.

A component can have:

one instance

or multiple instances

Each instance:

has its own state

receives its own props

has its own lifecycle

and keeps its own memory

I think of a component instance like a living object.
It exists in time, can change, can update, and React keeps track of it.


From Component Instance to React Element

Every component instance produces React elements.

React elements are created when JSX is converted into JavaScript using
React.createElement().

So in simple terms:

JSX is syntax

React element is the actual JavaScript object

Each React element describes what should appear in the UI.


React Element Tree and Virtual DOM

All React elements together form a React element tree.

Many people also call this tree the Virtual DOM.

This Virtual DOM plays a very important role in React.
Because of it, React is considered fast and modern.

The Virtual DOM allows React to:

compare UI changes efficiently

avoid unnecessary real DOM updates

update only what is actually needed


React Rendering (What It Really Means)

Now let’s talk about rendering, which is often misunderstood.

In React, rendering does NOT mean showing something on the screen.

Rendering means:

React’s internal process of calculating UI changes


When Rendering Is Triggered

Rendering is triggered mainly in two cases:

  1. Initial Rendering
    When we open a website and the UI appears for the first time.

  2. State Update Rendering
    When any state is updated inside a component.

This entire process happens inside React, not in the browser.


What Happens During Rendering

We already have a Virtual DOM tree.

When a state update happens:

React does not rebuild everything blindly

React re-renders the part of the tree from where the state was updated

Only the affected component and its child components are re-rendered

Parent components are not re-rendered unnecessarily

After that, React compares:

the previous tree

with the newly created tree

This comparison process is called reconciliation.


Fiber and Fiber Tree (Important Part)

Reconciliation is handled by React’s internal engine called Fiber.

Fiber has its own structure called the Fiber Tree.

Key things about the Fiber Tree:

It is created once

It is not recreated again and again

It keeps getting updated over time

The Fiber Tree looks different from the Virtual DOM tree, but it represents the same UI in a more optimized way.


Work-In-Progress Fiber Tree

When an update happens:

React creates a Work-In-Progress Fiber Tree

Changes are applied to this new tree

React prepares everything in the background

Once the work is complete:

The Work-In-Progress tree becomes the current Fiber Tree


Commit Phase

After reconciliation is done, React moves to the Commit Phase.

In the commit phase:

Changes are applied to the real DOM

Updates become visible

This whole process happens synchronously and is hidden from the developer.


Browser Rendering (After React Is Done)

After React finishes its work:

the browser takes control

the browser decides:

layout

painting

how things look on the screen

This is called browser paint, and this part is not React’s responsibility.


Complete Flow (As I Understand It)

This is the full flow in my head now:

Component creation

 → Component instance
 → React elements
 → React element tree (Virtual DOM)
 → Rendering trigger
 → Re-rendering
 → Reconciliation (Fiber)
 → Work-In-Progress Fiber Tree
 → Commit phase
 → Browser paint
Enter fullscreen mode Exit fullscreen mode

Final Thoughts

I believe this explanation is much better than what I understood earlier.

The most important realization for me is:

React rendering is about recalculating UI, not directly updating the screen.

I’m still learning, but this mental model feels solid and practical, and it helps me understand:

why re-renders happen

how React stays fast

and how updates actually reach the screen

This is my current understanding — and I’m confident it will evolve as I go deeper.

Top comments (7)

Collapse
 
dariomannu profile image
Dario Mannu

how React stays fast

As in... it doesn't at all?

Collapse
 
usama_dev profile image
Usama

🤔What do you think is the reason why React is so fast? That's all I understand so far.

Collapse
 
dariomannu profile image
Dario Mannu

no, it's not fast, it's one of the slowest, actually, if you look at the the benchmarks, let alone its massive weight.

Reasons? It's unnecessarily overcomplicated, overengineered in the wrong parts, poorly designed and based on some really creepy ideas, oversimplified where it should not, which ultimately leads to a scary number of bugs, unresponsive and very low quality web applications.

Thread Thread
 
usama_dev profile image
Usama

From your answer it seems like you are trying to say that React is slow overall, not because of the concept I explained. So can you tell me that React which has been popular in the web community for a long time because it is fast, modern and constantly updated, can you tell me which other framework is faster, more reliable and famous in the development community?

Thread Thread
 
dariomannu profile image
Dario Mannu

Everything on the left of the benchmark is fast, if that's what your'e looking for. But you'll need to look for more, not just raw speed. Critical thinking is your best friend.

"famous" or not, doesn't matter. Ignore that part, as it's just a cognitive bias, nothing objectively valuable by itself.

What makes something "famous"? Marketers designing cool banners and buying plenty of ad space to get them shown to millions, or tech influencers who don't even write code, just hope to pocket a percentage in exchange for their "hi guys, today I'm gonna show you" videos on Youtube.
So... how good and valuable can that "famous" stuff be, from the engineering point of view?

Is the standard web platform "famous"? Do you have millionaire youtubers talking about it all the time? No, because they have no monetary interest in doing so (Google and Big SaaS do, but it's a bit more indirect).

You think React is the next big thing to make you good money? Your're 10 years late. Now even your dog writes React using AI and works for cheap dog food and a bone, so the good money there is gone.

Event React itself, within Facebook, faced a crazy opposition initially, with most engineers saying it's total madness.

So, if all you want is getting a job quick, go for React. If you're after the truth, you want to create quality products instead of scamming the world, then keep learning as much stuff as you can, that's always good, and find what's really good for what you're doing.

Thread Thread
 
usama_dev profile image
Usama

I agree that React is not the fastest framework in raw benchmarks, and that popularity alone doesn’t equal engineering quality. My point wasn’t that React is magically fast, but that it performs well in real-world applications when used with the right architecture and trade-offs.
Every framework has strengths and weaknesses, and no single tool represents the truth. React happens to be a pragmatic choice for large, long-lived products, which is why it’s still widely used in production.
Ultimately, good engineering is about understanding trade-offs and choosing the right tool for the problem, not about chasing hype or dismissing tools entirely.

Collapse
 
adilson_rafael profile image
Adilson Rafael

Interessante, estou aprimorando meu conhecimento em React, mas acho ele um pouco lento sim