DEV Community: Manmeet Singh

React Native Fabric Rendering Explained

Manmeet Singh — Thu, 12 Mar 2026 12:17:51 +0000

In the previous article, we explored the legacy and new architecture of React Native, examining various components used in the new architecture. However, we did not delve deeply into the Fabric pipeline. Therefore, this article focuses on the Fabric Renderer and how React Native renders layouts.

What is Fabric Renderer

Fabric is React Native's new rendering system that utilizes the JavaScript Interface (JSI) and the Yoga layout library to render the native UI on the target platform. Unlike the old rendering system, which relied on a large JSON dump and was asynchronous, the new Fabric system uses JSI to directly invoke C++ methods, allowing for synchronous updates to the native layout without any performance drop.

Fabric rendering have multiple phases:

Render Phase: React executes the code and create a React Element tree which is then uses C++ to translate it to a React shadow tree.
Commit Phase: Yoga library uses the shadow tree and decided the exact mathematical coordinates of the components and decides the layout.
Mount Phase: Native side will render layout on the screen based on the information from the yoga tree

Let's say you want to render a <View> with a <Text> component inside it as shown in the code example below:

export default function HomePage(){
    return (
    <View>
       <Text>Home Page</Text>
    </View>
    )
}

Render Phase

In the Render phase, React executes the JavaScript logic, and for every React component, it creates a React Element tree. This is standard React behavior, while at the same time, the Fabric renderer steps in.

The Fabric renderer utilizes C++ to synchronously generate a Shadow element for each React Host Component (such as View or Text) from the React Tree, thereby creating a Shadow Tree.

The React Renderer establishes the same relationships among Shadow Node elements as React does among its multiple React Nodes, resulting in the creation of the React Shadow Tree.

As this step is performed synchronously using the JSI, there is no serialization overhead.

Now, we have the blueprint of what to draw on the screen, but we don't know the exact location or size of these individual nodes, hence we proceed to the commit phase.

Commit Phase

In the Commit Phase, the exact coordinates of the Shadow Nodes to be displayed on the screen are calculated. This involves two asynchronous operations: Layout Calculation and Tree Promotion.

Layout Calculation: During this step, the Renderer calls the Yoga Layout Library to determine the precise size (height and width) and coordinates (X and Y) for each shadow node in the React Shadow Tree. This layout calculation is primarily handled in C++, except in certain situations where component size or location must be computed on the host platform. In such cases, the Yoga library triggers a native function to perform these calculations on the native layer.
Tree Promotion: Once the layout math has been completed, then this React Shadow Tree is promoted as the official next tree, as it has all the information ready to be painted on the screen.

Both of the above operations are asynchronous in nature and executes on the background thread.

We have the blueprint, and we have the exact coordinates. The final step is to actually draw the native UI elements.

Mount Phase

Mount phase, transforms the C++ React Shadow Tree into Host View Tree, hence rendering the actual components on the screen.

So the React code we originally had, which looked like this:

<View>
<Text>HomePage</Text>
</View>

will be converted to its respective container called as Host View for each component and is then mounted on the screen.

Android

For Android, the View component will be converted to android.view.viewGroup and the Text component will be converted to android.widget.TextView and populates the text "HomePage" inside it.

iOS

For iOS, the View component will be converted to UIView and the Text component will be converted to UITextView and populates the text "HomePage" inside it with the help of NSLayoutManager.

Now the Mount Phase, itself consist of three different operations.

Tree Diffing: The C++ engine calculates the fundamental differences between the previously rendered tree and the new one. This process identifies minor changes, such as a background color alteration, to be applied to the UI, and then produces a list of necessary operations*.*
1. Note: If it's the initial render, the "previously rendered tree" is empty, so the resulting list will only include operations related to creating the views, setting properties, and so on.
Tree Promotion: The "next tree" officially becomes the "rendered tree". This can be used for further comparison in tree diffing in case of any state updates.
View Mounting: The calculated changes are applied to the native host views. This happens synchronously on the main UI thread.

The operations are synchronously executed on UI thread. If the commit phase executes on background thread, the mounting phase is scheduled for the next “tick” of UI thread. On the other hand, if the commit phase executes on UI thread, mounting phase executes synchronously on the same thread.

The above diagram shows the complete process of Fabric Rendering in React Native.

What Happens When State Changes?

Let's say a user taps a button and changes a background color from red to yellow. How does Fabric handle this without rebuilding everything?

React enforces immutability. To ensure thread safety, the React Shadow Tree cannot be mutated directly. Instead, React creates a new tree. But doing this from scratch every time would be a performance nightmare.

To solve this, Fabric uses Structural Sharing. When your state updates, React only clones the specific nodes that were affected by the change, plus their direct path up to the root. All the other unchanged components are simply shared between the old tree and the new tree. This drastically reduces memory consumption and makes state updates incredibly fast.

Conclusion

And there you go! Now you understand how React Native's new rendering system, "Fabric," works. Since we already covered the old and new architecture, you now have a solid foundation in the fundamentals of React Native.

React Native Architecture Explained

Manmeet Singh — Wed, 25 Feb 2026 04:42:41 +0000

If you’ve been doing web development for a while, chances are you rely on React to build your frontends. You ship a solid web app. It works well. Users like it and you realise it needs a mobile app.

You start researching and hit a wall, you need Kotlin for Android and Swift for iOS. You start questioning yourself: Do I really need to learn two separate languages? Master completely different tooling? Maintain two isolated codebases?

It sounds like an absolute nightmare. But just as you're about to give up, you stumble into the territory of cross-platform development and discover React Native. It’s a framework that lets you write mobile apps using JavaScript and React, tools you already know and with a single codebase that targets both Android and iOS natively.

Suddenly, building mobile apps doesn’t feel like starting from zero. It feels like an extension of what you already know. In this article, we are going to tear down React Native and understand exactly how its architecture works.

What is React Native

React Native is an open-source framework that allows developer to build native mobile applications for multiple platforms (Android, iOS, Mac, Windows) using JavaScript programming language and React library.

Unlike hybrid frameworks that render inside a WebView (essentially embedding a browser inside a mobile app), React Native renders real, platform-specific native components.

Let's take this code:

<View>
  <Text>Hello World</Text>
</View>

The above code does not translate into the HTML. Rather it's actually converted into the Native component of the specified platforms.

View will get converted to the ViewGroup component on Android and UIView on iOS, which are just native components, which acts as the layout containers, holding other components.
Text will get converted to the TextView component on Android and UITextView on iOS, which are again the native components, used to render the text on the screens.

They are the same building blocks you would use if you were writing the app directly in Kotlin or Swift. This means apps feel more like they belong on the device they're running on, offering a smoother and more responsive user experience.

How React Adapts to Web and Mobile

You might wonder how React, commonly used to build website front-ends, can also render native components for mobile operating systems. Is it really the same React used for the web?

Yes and no. The core React library is consistent across both web and mobile ecosystems, but the difference lies in how components are rendered.

Have a look at the diagram below:

To understand React Native, you need to understand a surprising truth i.e . React doesn't know how to render an UI on the Screen.

Look at the diagram above. At the very top sits the React Library. This is the brain of the operation. The function of the core react library is to manage the state using hooks such as useState and useEffect and calculates which part of the UI needs to be updated based on data changes using a process called Reconciliation. React library itself doesn't know what a HTML div is or what an android ViewGroup is.

That job of rendering the UI is done by the Renderer.

This architecture is what allows React to exist anywhere. You keep the same React Core at the top, but you swap out the Renderer depending on which platform you are targeting.

React-DOM Renderer: When building for the web, we use a renderer called react-dom. Since browsers natively understand JavaScript, the process is straightforward and synchronous in nature. The react-dom takes the blueprint from the react core and directly manipulates the DOM on the browser.
React-Native Renderer: Since Mobile platforms like Android & iOS doesn't understand the JavaScript natively, we require a different renderer known as react-native which takes the blueprint from react core and send it across the JS Bridge (old arch) asynchronously, which tells the mobile OS, to render the native component with specific properties (like color, size etc).

React does not render anything by itself. The renderer determines whether your components become DOM nodes or native UI views.

Now, we have a solid introduction of React Native, it's time to go behind the scenes with the architecture.

JS Bridge Architecture

The Bridge Architecture, also known as the Legacy Architecture, was how React Native applications originally worked. This was the default architecture before React Native v0.76.

Let's understand how the old architecture used to work.

Phase 1: Build Time (The Setup)

In the build phase, all the JavaScript code, react components, assets are taken from our codebase and are bundled into a single optimised file known as JS Bundle using the Metro Bundler.
This static bundle is the blueprint of your entire application and is embedded with your application during the build time.
Once the app is installed, Metro is no longer involved. Everything from this point forward happens at runtime.

Phase 2: Run Time (The Execution)

When the user taps on your app, three different threads are fired for execution of our app:

JavaScript Thread: The JavaScript Engine (JSC) would boot up and start executing the JS Bundle which is embedded in our app. This is where our JavaScript code will be executed and holds all the react logic, state and performs the API calls as well to fetch the data.
UI Thread: The UI thread will spawn on your mobile OS, which will allow it to paint the initial UI of the app for the interaction based on the instructions it received.
Shadow Thread: This thread will be used by the Yoga Library, that will calculate the entire layout of the app and provides the instructions to the UI Thread on how to render the layout.

Phase 3: Execution Phase

Whenever a user taps on the button, let's say this button will change the colour of the background, then firstly the UI Thread will capture the Tap event on the button.
Since the Native UI cannot execute a JavaScript function directly, it will serialize the touch event into a JSON and will send this even to the asynchronous bridge.
The JS Bridge will sent this information to the JavaScript engine (JSC), which will deserialize the JSON, process the JavaScript code, let's say update the state using useState and React calculates the new UI based on the changes.
The JS Thread now serializes these instructions in the JSON format and will again send it to the asynchronous bridge.
The Shadow Thread will receive this JSON, and the Yoga library will read these instructions and will calculate exact coordinates and properties of the element and will pass it to the UI Thread to finally paint the updated screen.

Limitations of the Asynchronous Bridge

There were a few limitations of the asynchronous bridge but the biggest ones were the bridge and the JSON, as you can see from the diagram above.

Serialization Bottleneck: Since mobile platforms and JavaScript cannot directly communicate, they rely on JSON for interaction. Stringifying and parsing JSON costs CPU cycles. This serialization and deserialization process through the asynchronous bridge introduces significant latency, and handling a large number of events can lead to lag and frame drops on the native side.
Asynchronous Bridge: The serialization and deserialization process isn't inherently problematic, but the issue arose from relying on a single asynchronous bridge. Because JavaScript cannot directly interact with the native side to modify the UI, each event must pass through the entire message-passing phase on the bridge. With a large volume of JSON messages, the bridge often becomes congested, leading to frame drops, laggy animations, and the notorious blank white screens when rendering lists.
Single JavaScript Thread: All code processing must occur on the JavaScript Thread. Although there are separate threads, such as UI Threads, the majority of application logic is managed by the JavaScript thread. Consequently, intensive computations can block this thread, leading to noticeable performance declines across the entire app.

Since, React Native doesn't block the Main Thread, that's why everything needs to be done in asynchronous way. Hence every event becomes a promise/callback.

New Architecture

The React Native core team soon understood that optimizing the JSON Bridge wouldn't lead to the desired performance improvements. Therefore, they chose to eliminate the asynchronous JS Bridge altogether.

The bridge has now been replaced with the JavaScript Interface (JSI), featuring C++ bindings that directly call the native API of mobile platforms, bypassing the serialization/deserialization and message-passing process. This enhances the overall app performance.

Hermes Engine

Hermes Engine is an open source JavaScript engine created by Meta for improving the performance of the React Native apps.
It is heavily optimized for the React Native and uses JSI to directly communicate with the native platforms using Native APIs.
It provides other benefits like Improved time to interactive (TTI), smaller app bundle size and reduced memory consumption.
It replaced the old JSC and became the default for React native apps starting from version 0.70 of RN.

JavaScript Interface (JSI)

JavaScript Interface (JSI) is the new lightweight C++ layer that allows the JavaScript to directly communicate with the Native code.
JSI replaced the old legacy bridge architecture which means that no message passing or asynchronous operations are required.
JSI allows JavaScript to hold the references to C++ host objects and invoke methods directly on them in a synchronous manner.

Because of JSI, JavaScript can now hold direct references to C++ Host Objects e.g. nativeObjectRef. When JavaScript calls nativeObjectRef.setProperty(), it isn't sending a JSON message to a queue; it is synchronously invoking a method on the C++ object located in the native side.

Turbo Modules

In legacy architecture, if you need to use some native functionality such as Bluetooth, camera etc, then those native modules were loaded eagerly, on the startup and stayed loaded in the memory in case they were needed later.
Due to these reasons, in legacy architecture the native modules would take more time to load, significantly increase the memory footprint and makes the app slow.
However with introduction to Turbo Modules in the new architecture, now these modules are lazily loaded.
As turbo modules are loaded only when they are required, this allowed to reduce the memory footprint and also enhances the performance a lot.

Fabric System

Fabric is the new rendering system which utilizes the JSI and Yoga library to manage the UI on the native side.
In the legacy architecture, if JavaScript wanted to render a massive list, it had to serialize a huge JSON payload, dump it into the queue, and hope the UI thread wouldn't drop frames. It was asynchronous in nature.
With Fabric, JavaScript uses JSI to directly invoke the C++ methods that create and update the native views (like UIView on iOS or ViewGroup on Android) synchronously.
Fabric render pipeline have multiple phases:
1. Render Phase: React executed the code and create a React Element tree which is then uses C++ to translate it to a React shadow tree.
2. Commit Phase: Yoga library uses the shadow tree and decided the exact mathematical coordinates of the components and decides the layout.
3. Mount Phase: Native side will render layout on the screen based on the information from the yoga tree

In this article, I am not going into the workings of the Fabric, but may create a separate article in future for this.

Conclusion

At this point, you have a solid understanding of what React Native is and exactly how it operates under the hood.

We've explored how the Legacy Architecture functioned, why the asynchronous JSON Bridge became a major performance bottleneck, and how the React Native core team solved it by rewriting the engine with C++ and JSI.

What are you waiting for? Go build that app!

A Beginners Guide to DNS Resolution

Manmeet Singh — Thu, 05 Feb 2026 18:24:44 +0000

Whenever you try to open a website, like "google.com," what do you think happens behind the scenes? How does your browser know which server to get data from among millions of servers worldwide? Is it magic? Well, No! It happens with the help of a system known as DNS.

Before we understand this complex system, let’s understand the working of DNS with the help of an Analogy.

Phonebook Analogy

Our smartphones have an app named Contacts, which stores all the phone numbers of our friends, family and other people whom we meet in our life.

Let me ask you this question; Do you remember the phone numbers of all people stored on your mobile?

Most likely, your answer would be no (unless you're a genius or very lonely)! Generally, you might only remember a few phone numbers of your close ones, like your parents. However, you do remember most people's names, and when you need to call them, you open your phone app, search for the person's name, and click the call button. Your phone then automatically dials the number for you.

You see, we humans are not great at remembering numbers, but we are excellent at remembering names. So, we use our contacts app to save a person's name and phone number once, and then our phone app does all the hard work for us.

Just like people have name and phone numbers, the websites have Domain Name and IP Addresses and we really remember websites names like Google, Instagram, Reddit but not their IP Addresses.

Entity	Name	Number / IP Address
Person	John Doe	+1034024234
Website	Google.com	172.217.19.164 (Real IP btw)

DNS acts like the internet's phonebook. It converts a Domain Name (e.g., Google.com) to its corresponding IP Address (e.g., 172.217.19.164).

Just as we rely on our contacts app to convert a name into a phone number, a web browser like Chrome relies on DNS to convert a domain name into an IP address.

However, your phonebook is probably small with maybe about 500 to 1,000 entries max. But there are millions of websites on the internet. Do you think a single phonebook could handle it all?

Well, No.

It’s not just one massive server; it’s actually many different systems working together. We call this a Decentralised System."

What is DNS

Domain Name System (DNS) is a hierarchal and distributed naming system that converts the human readable domain names into their respective IP addresses which are used by the client such as web browser to access those websites.

In the diagram above, the DNS system is shown as a single component for simplicity, but it actually consists of multiple different components.

Components of DNS System

Recursive Resolver: Recursive Resolver is the server that is provided by your Internet Service Provider (ISP) and is the main bridge between your System and the other DNS servers.
- The name Recursive comes from the fact that it makes request to multiple DNS servers in order to get the IP address of the final server. It is also the initial point of contact between client and the global DNS system.
Root Servers: Root Servers provide the IP Address of the servers which contains the records of the top level domains (like .com or .net) and share them with the Resolver.
- There are technically only 13 Root Server IP addresses in the world. However, don't worry about them crashing—there are actually 1,600+ physical servers worldwide using "Anycast" technology to share those 13 IPs. It’s a massive, distributed safety net.
Top Level Domains: These servers have domain specific and only contains the IP address for the domains that correspond to the specific TLD (e.g .com). This server provides the IP of the Authoritative Servers.
- TLD are also of different types such as Country Specific (.jp, .in, .ca etc) and Generic (.com, .org, .net etc).
Authoritative Server: These are the servers which holds the actual IP address of the website, you’re trying to visit.
- There’s a common misconception that Authoritative servers are the final servers where the website is hosted. However, this Idea is wrong!
- When you buy a domain (from GoDaddy, Namecheap, etc.), they usually provide this server by default. However, as developers, we often configure this to point to a custom provider like Cloudflare or AWS Route53 for better speed and security.

DNS Resolution Process

Now, let's understand how your web browser loads websites using a process called DNS Resolution.

A user opens the web browser, types the URL (e.g., https://google.com), and presses enter.
The browser will try to find the website's IP address in its local cache. If it finds the IP address, it will load the website, and the rest of the DNS resolution process is skipped.
If the IP address of the website is not found, the DNS query is sent to the Recursive Resolver.
The Recursive Resolver will also check its cache to see if the IP address is available. If it is, the resolver will return the response to the browser, and the rest of the DNS resolution process will be skipped.
If the IP address of the website is not found in the Recursive Resolver’s cache, the request is sent to the Root Servers.
Root Servers check the top-level domain in the URL (like google.com) and provide the IP address of the Top Level Domain Server for .com domains to the Recursive Resolver.
The Recursive Resolver then sends the request to the Top Level Domain Server, which checks the registrar currently handling the website and returns the IP address of the Authoritative Server to the Recursive Resolver.
The Recursive Resolver sends the request to the Authoritative Servers, which provide the actual IP address of the website server (in this case, Google’s server) to the Recursive Resolver.
The Recursive Resolver returns the response to the browser.
The browser then sends the request directly to the website’s server using the IP address provided by the Recursive Resolver and retrieves the data from the website.

Time To Live (TTL)

So far, we have learned the 10-step DNS resolution process. But now, a question might be popping up in your head: “**Does this long, complex process happen for every single resource?**”

Think about it for a second!

Let’s say you have a slow internet connection. The DNS resolution itself takes about 2 to 3 seconds, and finally, the webpage loads. However, a modern webpage isn't just one file. It has images, scripts, fonts, and videos. If that page has 10 images, and your browser had to perform a full DNS resolution for every single one, that would be an extra 10 lookups. At 3 seconds per lookup, you are looking at a 30-second delay just to find the images!

In the world of modern web development (React, heavy JavaScript, rich media), this would be a disaster. The web would be unusable.

So what’s the fix? Well, one word Caching.

Remember, in the DNS resolution step, both the browser and the recursive resolver have a cache, which helps the browser avoid repeating the entire DNS resolution process.

Great, so the browser doesn't need to make requests repeatedly to get the IP address for images and other resources. But who tells the browser when to check the cache again?

Imagine your browser cached a website, and then a developer switched to another server a minute later. If the browser never checks with the recursive resolver again, how would it know the website's IP address has changed?

This is where the concept of Time To Live (TTL) comes into play.

TTL is a setting attached to the DNS record (configured by the domain owner). It tells the resolver exactly how long to keep the data valid.

High TTL : This is good for the websites, that are stable and don’t change as often. High TTL could be like 24 hours of time is beneficial for such websites.
Low TTL : This is good for the websites, that are change regularly. Low TTL could be like 5 minutes of time is beneficial for such websites.

Essentially, TTL is the expiration date on the data. It ensures your browser remains fast by not making too many request to DNS servers but at the same time doesn’t keep serving the Stale data.

Dig Command

So far, we just learned about the theory. Shall we try seeing this in practice?

We can achieve this using the dig (Domain Information Groper) command. It’s a standard tool for developers to query DNS servers directly and see exactly what is happening under the hood.

Open your terminal and type:

dig google.com

Just take a look at the output below.

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22386
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     280 IN  A   142.250.182.206

;; Query time: 20 msec
;; SERVER: 2405:201:5500:6193::c0a8:1d01#53(2405:201:5500:6193::c0a8:1d01)
;; WHEN: Sat Jan 24 16:50:36 IST 2026
;; MSG SIZE  rcvd: 55

The output might look like a wall of text, but let's decode the three most important parts:

Question Section: Contains the query that we sent, In our case to get the IP of google.com
Answer Section: Contains the information about the response we received. This includes information like:
1. Domain Name: google.com
2. Time to Live (TTL): 280 seconds
3. DNS Record Type : A record
4. IP Address : 142.250.182.206
Additional information: This contains some additional information about the Query such as:
1. Query time: It took 20 milliseconds for this query to return response.
2. Server: This is most likely our Recursive Resolver

Seeing the full DNS Resolution using the Dig command

Now with all the knowledge equipped about the DNS and how the Dig command shows the results, are you ready to see full DNS Resolution in action?

Let’s run the dig command with +trace flag.

dig google.com + trace

Just take a look at the output below.

 ~/ dig google.com +trace

; <<>> DiG 9.10.6 <<>> google.com +trace
;; global options: +cmd
.           86363   IN  NS  a.root-servers.net.
.           86363   IN  NS  b.root-servers.net.
.           86363   IN  NS  c.root-servers.net.
.           86363   IN  NS  d.root-servers.net.
.           86363   IN  NS  e.root-servers.net.
.           86363   IN  NS  f.root-servers.net.
.           86363   IN  NS  g.root-servers.net.
.           86363   IN  NS  h.root-servers.net.
.           86363   IN  NS  i.root-servers.net.
.           86363   IN  NS  j.root-servers.net.
.           86363   IN  NS  k.root-servers.net.
.           86363   IN  NS  l.root-servers.net.
.           86363   IN  NS  m.root-servers.net.
;; Received 239 bytes from 127.0.2.2#53(127.0.2.2) in 1 ms

com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            86400   IN  DS  19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.            86400   IN  RRSIG   DS 8 1 86400 20260206050000 20260124040000 21831 . E/ZKdBG6pUCuQGB0jkM1cndavlviGO62WgLfbmQPNEz/YY7sufjwe8Jp pQA3VU9dgd46/E+90p9q8LnK1pdGm7k0RJlA+XuvenHdXVbX+jzZn+N5 p0+fEsbociE7ot1/JmwKacwPPPKtnrep8iRELxXHU20BA4J/0sp3z9ht 8+2WgDoaQlKb04JQf5eS0J1hJ+mAELQbQKwWXxX8yaisSObq9axWIAKE NHUv4PO82pBf3BMwLLdZhzlfVoX/ObjcDoTm6yhHkhavB9hNOil8o6kA gg0MMcsbJqEGBrgVT1pKn9pDabUR949GFL8Qo1eHm270Dp72F8E+tfE9 ud4Nyw==
;; Received 1170 bytes from 193.0.14.129#53(k.root-servers.net) in 36 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20260130002721 20260122231721 35511 com. FRwJDTYcGgEr+lzbONMVnFNDkoYtjSmaKNF0x+q4JR+sD+rwZDoaYn/D rPkDTs5F1BwixFGXqZQizSc7cFjkdw==
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8  NS DS RRSIG
S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN RRSIG NSEC3 13 2 900 20260131013349 20260124002349 35511 com. uW9ufLSEVTnIol0z4l+DX8pBSOvPIVaJSeFV8EE7cYJOgu44vzXw0rus XnZN3Zj/y6mjTGmDpGd4QHBnIevvYg==
;; Received 644 bytes from 192.54.112.30#53(h.gtld-servers.net) in 352 ms

google.com.     300 IN  A   142.250.182.46
;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 26 ms

Let's look at the actual output and decode the journey.

Step 1: The Root Check (.)

.           86363   IN  NS  a.root-servers.net.
.           86363   IN  NS  b.root-servers.net.
...
;; Received 239 bytes from 127.0.2.2#53(127.0.2.2) in 1 ms

It first queries the Root Servers and picked one of the random servers from the 13 root servers and get’s the IP of TLD server and proceeds to step 2.

Step 2: The TLD Check (com.)

com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
...
;; Received 1170 bytes from 193.0.14.129#53(k.root-servers.net) in 36 ms

Now our computer asked the TLD server k.root-servers.net, about the IP of google.com. However it responded with IP of the Authoritative Server.

Step 3: The Authoritative Check (google.com.)

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
...
;; Received 644 bytes from 192.54.112.30#53(h.gtld-servers.net) in 352 ms

Now our computer asked the Authoritative Server h.gtld-servers.net, about the IP of google.com. It responded with NS ns2.google.com, telling us to ask the IP from google servers directly.

Step 4: The Final Answer

google.com.     300 IN  A   142.250.182.46
;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 26 ms

Our computer sent a request to ns3.google.com which gave us the final IP: 142.250.182.46 and we can now open google.com on our system.

Conclusion

If you've followed along this far in the blog, congratulations! You now understand that DNS is not magic but a complex system that required a lot of engineering to get to where it is today.

CURL Command Explained

Manmeet Singh — Thu, 05 Feb 2026 18:19:33 +0000

In today's world, we mostly use Client-Server Architecture, which means multiple clients connect to a centralized server. Of course, there can be multiple servers and distributed systems too, but to understand the Curl command, we'll focus on one client and one server.

Before we dive into the cURL command and how it works, let's first understand the client-server architecture.

What is Server?

A server is a computer system that is always connected to the Internet, listening for incoming requests, and providing appropriate responses.

There are different types of servers, such as application servers, database servers, and mail servers.

Servers play a crucial role in the client-server architecture by ensuring that clients receive the necessary data and services they request. Understanding how servers work helps us use tools like cURL more effectively to interact with these systems.

What is a Client?

A client is anything a user controls, from a web browser to a terminal, that can send requests to a server and receive responses to display to the user.

A client can be a web browser like Chrome or Firefox, an API testing tool like Postman or Bruno, or terminal software like cURL.

Client-Server Architecture

Client Server Architecture simply says that a client will send a request using REST API (or any other API) to the server, the server will process the request and will send the response appropriately to the client.

Request will contain information such as the route (URL Path), HTTP Method (POST, GET, etc), Headers (e.g. content-type) and the body, which will contain the payload or any data, that is required by the server to perform the operations.

Response will also contain information such as the HTTP Status (e.g 200, 201), implying the result of operation, Response Headers (e.g. content-type) and the body which is the payload, that will tell the client about the status of the operation.

We will not dive deep into more things but just keep in mind that client sends request to the server and server provides the response. Now let’s proceed to our main topic cURL.

What is cURL

cURL is an utility or an software that allows us to send an request to the server, receive the response and show the data appropriately inside the terminal.

It can also upload and download files from the web servers and also support multiple protocols such as FTP, SMTP, Telnet and more, hence making this a really powerful utility for connecting with servers.

Why Programmers loves cURL

Well, there’s many reasons programmers love cURL command and many even like using this command over other software.

No Installation needed: For many programs such as Postman or Chrome, they need to be installed on the OS, but cURL usually comes pre-installed on all modern OS, making it much easier to switch to any OS and start working immediately from the terminal using cURL.
Great for No-GUI environments: Many times when working on servers, we don’t have access to GUI programs and this is where the cURL utility really shines. It doesn’t have any fancy UI and can work from the terminal as CLI application.
Lightweight: cURL is a very lightweight software unlike other clients such as chrome or postman.
Multiple Protocol Support: cURL supports multiple protocols which clients like chrome don’t and with option to upload/download files from server as well, really makes it a great utility.

Now, that we understood what is cURL and why programmers love it. You might be thinking; “Hmm, okay but then why we learned the client-server architecture first?”

Well, because, now we are going to learn the cURL commands and try sending headers, payloads and other information as well.

Basic cURL Commands

Let’s understand some basic cURL commands, that we can use in our everyday life as developers.

Fetch the Webpage

To fetch the webpage from the a server, we can use the command:

curl https://google.com

Response we got from the server was:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

So, you can see that the server replied us with 301 status code with message document was moved. This happens because the basic cURL command will not follow up with the redirects.

We can use -L flag which means follow redirects

curl -L https://google.com

Response we get from the server was:

Hence the -L flag will follow the redirects and will print the entire HTML code from the webpage on the terminal.

View the Response Headers

Headers are sent by the server as the response. To view the headers we can use -I flag.

curl -I https://google.com

Response we get from the server is:


 ~/Developer/cohort/curl/ curl -I https://google.com
HTTP/2 301
location: https://www.google.com/
content-type: text/html; charset=UTF-8
content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-B_J2kdosi1cTamYOJzeVxg' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
date: Tue, 27 Jan 2026 12:40:23 GMT
expires: Thu, 26 Feb 2026 12:40:23 GMT
cache-control: public, max-age=2592000
server: gws
content-length: 220
x-xss-protection: 0
x-frame-options: SAMEORIGIN
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

You can see the headers that was sent by the server as response to our client, being shown in the terminal. However these are only the headers, if you want to see Headers + Response, then use the -i flag.

curl -i https://google.com

Response we get from the server is:

 ~/Developer/cohort/curl/ curl -i https://google.com
HTTP/2 301
location: https://www.google.com/
content-type: text/html; charset=UTF-8
content-security-policy-report-only: object-src 'none';base-uri 'self';script-src 'nonce-1k2aoSXbjjeLVNgA55J97A' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/other-hp
date: Tue, 27 Jan 2026 12:42:23 GMT
expires: Thu, 26 Feb 2026 12:42:23 GMT
cache-control: public, max-age=2592000
server: gws
content-length: 220
x-xss-protection: 0
x-frame-options: SAMEORIGIN
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

From the above response, you can see that the Headers are being displayed along with the response sent by the server.

Send Request Headers to the server

We have seen the response headers, that server send as the response. However, we can also send some headers from our client to the server.

We can use -H flag followed by Header-Name: value along with our cURL command to the server.

 curl -H "content-type:application/json" https://google.com

Receive Payload from the Server

As seen from our client-server architecture, we can receive, the payload from the server. We can specify the HTTP method using -X flag, followed by the HTTP method such as GET, POST etc.

curl -X GET https://jsonplaceholder.typicode.com/posts/1

Response we get from the server is:

 ~/ curl -X GET https://jsonplaceholder.typicode.com/posts/1
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

You can see the payload we received from the server.

Send Payload to the Server

To send some data (payload) to the server, we can use the POST method. We can also pass headers using -H flag and data using -d flag if necessary.

# make sure they are in same line, I just seperated them to make it more visible
curl -X POST \
  -H "content-type: application/json" \
  -d '{"name": "Manmeet", "role": "admin"}' \
  https://jsonplaceholder.typicode.com/users

Response I get from the server was:

 ~/ curl -X POST -H "content-type: application/json" -d '{"name" : "Manmeet", "role":"admin"}' https://jsonplaceholder.typicode.com/users
{
  "name": "Manmeet",
  "role": "admin",
  "id": 11
}

Here, you can see that the data included my name and role as manmeet and admin, which the server acknowledged and sent me as a response for the confirmation, that my data was received by server.

You can also use other methods such as PUT, PATCH, OPTIONS, DELETE as well.

Filtering Data with Query Parameters

Sometimes, you don't want the server to send back everything. You might want to filter the data, limit the number of results, or sort them. In Client-Server architecture, we usually handle this by passing Query Parameters directly in the URL.

Query parameters start with a ? after the URL path. Multiple parameters can be separated by the ampersand & symbol, like /users?_limit=5&search=A.

Let's say we want to fetch posts from the server, but we only want the top 5 results, and specifically for user ID 1. We can combine these using parameters provided by the JSONPlaceholder API.

curl "https://jsonplaceholder.typicode.com/posts?_limit=5&userId=1"

The server will return an array containing only 5 post objects that belong to User 1, rather than the full list.

Downloading Files (`-o`)

Sometimes the response isn't text as it could be a massive JSON, an image, or a zip file. Printing this response to server will cause a mess, making it harder to understand.

Use the -o (output) flag to save the response to a file.

# Save the Google homepage source code to a file named 'google.html'
curl -o google.html https://www.google.com

Above command will create a new file google.com and will print the source code of google.com webpage inside it.

Debugging with Verbose Mode (`-v`)

As a developer, things will break. Maybe your API returns a 500 Error, or your authentication fails. This is where curl becomes a diagnostic tool.

The -v (verbose) flag tells cURL to show the entire conversation—the handshake, the hidden headers, and the raw traffic.

curl -v https://google.com

Understanding the Output:

Lines starting with * show the connection process (DNS resolution, SSL handshake).
Lines starting with > are the data you sent (Request).
Lines starting with < are the data received (Response).

This gives you "X-Ray vision" into the HTTP protocol.

Conclusion

We started this journey understanding the Client-Server Architecture because tools are useless if you don't understand the system they interact with. We then moved to cURL, exploring how to fetch pages, inspect headers, and send data using methods like POST. While graphical tools hide the complexity, cURL forces you to understand the raw HTTP protocol. It makes you think about headers, payloads, and status codes. This doesn't just make you better at using the command line; it makes you a better Backend Developer.

Web Browser Internals Explained

Manmeet Singh — Thu, 05 Feb 2026 17:56:43 +0000

We all use web browsers every day. Whether it's surfing social media, watching videos on YouTube, or doing a quick search, browsers have become such an essential part of our lives that we hardly notice them. However, behind this impressive technology is some great engineering, and that's what we will explore today.

Before we dive in deeply, let's first address the obvious question: What exactly is a web browser?

What is a Web Browser

A web browser is a software application used to access and retrieve information and resources from the World Wide Web, acting as an interface between the user and the internet. Simply put, a web browser is an application that lets a user visit websites.

Technically Speaking, A browser is a compiler and rendered which takes the raw text resources like HTML, CSS and JS and convert them into the visual representations on the screen.

There are some excellent web browsers available, such as Chrome, Edge, Firefox, Safari, and Brave.

Components of Web Browser

A web browser consists of multiple components such as:

User Interface: This is the Graphical User Interface (GUI) part of the browser that the user can see and interact with. For example, in the Chrome browser, this includes the opening window with an address bar, bookmarks, shortcuts, and similar UI features that a user can see and interact with.
Browser Engine: This part acts as the bridge between the User Interface (UI) and the Rendering Engine.
Rendering Engine: This is the core of the browser. It transforms documents like HTML and CSS into their respective trees (DOM & CSSOM), which are used to display content on the webpage. In other words, it turns code into pixels. There are many rendering engines, such as Blink, Gecko, and Webkit.
Networking: This component is very useful for performing network operations like DNS resolution and fetching resources such as HTML, CSS, and images from servers.
JS Interpreter: This component runs the JavaScript code on our website. It is also known as the JavaScript engine which parses and executes the JavaScript code. Modern Engines also use JIT (Just In Time) Compilation to speed up this process. There are many popular JavaScript engines, such as V8, SpiderMonkey, and WebKit.
UI Backend: This component interacts with the operating system and allows the display of UI components to users, such as windows and buttons in the browser's interface.
Disk Persistence: This Layer lets the browser store and retrieve data from the system's storage with the operating system's permission. This includes storage options like Cookies, LocalStorage, and SessionStorage.

How a WebPage is Rendered?

Now let’s go behind the scenes, of what happens when you enter a URL and access a website on the browser.

When you type a URL into the browser (e.g., thatsmanmeet.com), the Network Layer handles DNS resolution and sends a request to the server. It retrieves resources like HTML, CSS, and other elements such as images and fonts.
Once the HTML and CSS are fetched, these documents are sent to their respective Parsers. The Parser converts the raw text in these files into their respective Object Models.
1. For HTML, the raw text like <p>Hello</p> is broken into tokens and converted into objects known as Nodes. A Node is a single element or component on the webpage that represents an HTML element. These Nodes are arranged into a tree-like structure known as the Document Object Model (DOM).
2. For CSS, the raw text file is also broken into tokens and then parsed into another tree-like structure known as the CSS Object Model (CSSOM). This tree represents all the styles associated with the DOM Nodes. This step is important because the browser needs to decide which rule takes precedence among the browser default, user-defined stylesheets, or inline styles.
Once both the DOM and CSSOM trees are built, they are combined into a single structure called the Render Tree. This process is also known as frame construction in the Gecko Engine. This structure only includes the elements that will be visible on the webpage. Therefore, the Render Tree determines which elements will be displayed on the webpage.
1. Elements with the display:none CSS property exist in the DOM but not in the Render Tree.
2. Elements with visibility: hidden exist in both the DOM and Render Tree, but they take up empty space.
3. Meta tags like <head>, <meta>, <script>, etc., are also excluded from the Render Tree.
Now that our parsing phase is complete, the browser will begin the rendering process.
At this point, the browser knows what to draw or render, thanks to the Render Tree, but it doesn’t know where each element should be placed on the page. For example, it doesn’t know whether the footer should be at the top or bottom of the page. This is where the next phase, Layout (Reflow), comes into play.
In the Layout (Reflow) phase, the browser calculates the exact position and size of every element in the Render Tree to be shown in the viewport. It also determines the exact pixel coordinates of every frame (box), taking into account padding, margins, borders, and other information. This is a computationally expensive process.
Now the browser knows where to draw everything. Next comes the Painting process, which converts the layout into pixels. The browser fills in the pixels with text colors, background images, images, shadows, borders, etc. This is usually done in multiple layers, similar to how Photoshop works.
Finally, we reach the Display phase, which includes another process known as Compositing. Since the browser paints in layers, it needs to flatten the layout to display it properly on the screen. Through the process of compositing, the image is finally displayed on the screen.

The JavaScript Interruption

You might have noticed that we didn't mention JavaScript in the flow above. That is because strictly speaking, JavaScript is an interruption to the rendering process.

When the HTML Parser is happily building the DOM and encounters a <script> tag, everything stops.

The browser stops building the DOM because it doesn't know what changes the JavaScript might make, such as adding, removing, or editing elements. So, the browser hands control over to the JavaScript Engine (like V8) to interpret and run the JavaScript code.

Only after the JavaScript finishes running does the Rendering Engine continue building the DOM. This is why it's usually recommended to place <script> tags at the end of HTML documents, just before the closing body tag, so the DOM construction isn't interrupted.

If a <script> tag is placed inside the <head> and the JavaScript file being loaded is quite large, the user would just see a blank white or black page, which would be a poor user experience.

Reflow vs Repaint

It is often confusing to understand the difference between Reflow and Repaint, but distinguishing between them is crucial for writing performant CSS.

Reflow: Reflow happens when you change the layout or geometry of the page. The browser has to re-calculate the positions and dimensions of elements. Changing properties like width, height, margin, position, or resizing the browser window. This is computationally expensive as single element causing reflow can cause browser to recalculate the layout for its parents and children as well.
- Example: You hover over an element and it expands from 200px to 400px, pushing all other text down.
Repaint: Repaint happens when you change the look of an element without changing its size or position. Changing properties like color, background-color, or visibility. This skips the Layout phase entirely and is much faster than a Reflow because the browser doesn't need to do any geometry calculations.
- Example: You hover over a button and its background color shifts from blue to dark blue.

Conclusion

A browser is far more than just a window to the internet. To the average user, the web feels like magic. But as developers, we now know it is actually a precise feat of engineering. You now understand exactly what happens under the hood from the moment a URL is typed to the millisecond the pixels appear on the screen.

DEV Community: Manmeet Singh

React Native Fabric Rendering Explained

What is Fabric Renderer

Render Phase

Commit Phase

Mount Phase

What Happens When State Changes?

Conclusion

React Native Architecture Explained

What is React Native

How React Adapts to Web and Mobile

JS Bridge Architecture

Phase 1: Build Time (The Setup)

Phase 2: Run Time (The Execution)

Phase 3: Execution Phase

Limitations of the Asynchronous Bridge

New Architecture

Hermes Engine

JavaScript Interface (JSI)

Turbo Modules

Fabric System

Conclusion

A Beginners Guide to DNS Resolution

Phonebook Analogy

What is DNS

Components of DNS System

DNS Resolution Process

Time To Live (TTL)

Dig Command

Seeing the full DNS Resolution using the Dig command

Conclusion

CURL Command Explained

What is Server?

What is a Client?

Client-Server Architecture

What is cURL

Why Programmers loves cURL

Basic cURL Commands

Fetch the Webpage

View the Response Headers

Send Request Headers to the server

Receive Payload from the Server

Send Payload to the Server

Filtering Data with Query Parameters

Downloading Files (-o)

Debugging with Verbose Mode (-v)

Conclusion

Web Browser Internals Explained

What is a Web Browser

Components of Web Browser

How a WebPage is Rendered?

The JavaScript Interruption

Reflow vs Repaint

Conclusion

Downloading Files (`-o`)

Debugging with Verbose Mode (`-v`)