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:

1. 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.

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

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.

1. 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.

2. 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.

1. 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.

2. 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.

3. 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.

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.

1. 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.

2. 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)

1. 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.

2. This static bundle is the blueprint of your entire application and is embedded with your application during the build time.

3. 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:

1. 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.

2. 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.

3. 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

1. 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.

2. 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.

3. 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.

4. The JS Thread now serializes these instructions in the JSON format and will again send it to the asynchronous bridge.

5. 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.

1. 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.

2. 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.

3. 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

1. Hermes Engine is an open source JavaScript engine created by Meta for improving the performance of the React Native apps.

2. It is heavily optimized for the React Native and uses JSI to directly communicate with the native platforms using Native APIs.

3. It provides other benefits like Improved time to interactive (TTI), smaller app bundle size and reduced memory consumption.

4. It replaced the old JSC and became the default for React native apps starting from version 0.70 of RN.

JavaScript Interface (JSI)

1. JavaScript Interface (JSI) is the new lightweight C++ layer that allows the JavaScript to directly communicate with the Native code.

2. JSI replaced the old legacy bridge architecture which means that no message passing or asynchronous operations are required.

3. 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

1. 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.

2. 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.

3. However with introduction to Turbo Modules in the new architecture, now these modules are lazily loaded.

4. 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

1. Fabric is the new rendering system which utilizes the JSI and Yoga library to manage the UI on the native side.

2. 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.

3. 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.

4. 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!

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:

1. 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.

2. Browser Engine: This part acts as the bridge between the User Interface (UI) and the Rendering Engine.

3. 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.

4. Networking: This component is very useful for performing network operations like DNS resolution and fetching resources such as HTML, CSS, and images from servers.

5. 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.

6. 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.

7. 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.

1. 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.

2. 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.

3. 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.

4. Now that our parsing phase is complete, the browser will begin the rendering process.

5. 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.

6. 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.

7. 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.

8. 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.

That's where Emmet comes in.

What is Emmet?

Emmet is a plugin for text editors and IDEs that allows for quick auto-completion and editing of code in languages like HTML, XML, XSLT, CSS, and others.

Think of Emmet as a fast autocomplete, similar to the autocomplete feature on your mobile keyboard, but for coding.

In the past, Emmet was available only as a plugin that needed to be manually installed in the code editor to enable fast auto-completion and other features. However, now Emmet is built into most code editors like VS Code, Cursor, and WebStorm, and is available as a plugin for editors like Notepad++ and Sublime Text.

When it comes to languages like HTML, Emmet can be thought of as a shortcut language. Let me explain.

Emmet for HTML

I’ll give you a task; write down the basic structure of the HTML in your favourite code editor.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>

</body>
</html>

You might type the code example above line by line, right? Now, let me show you a shortcut using Emmet. Open your favorite text editor with Emmet installed (I'll be using VS Code), create a new file named index.html, type an exclamation mark !, and press enter.

See, when I typed ! and pressed enter, the entire HTML structure was instantly added to the text editor.

Isn't that awesome? We skipped all the manual typing of the HTML code snippet, and Emmet did it automatically for us.

Now, let’s learn some more HTML snippets to make our coding super fast ⚡️.

Creating HTML Elements Using Emmet

All you need to know are the basics of HTML, such as tags, attributes, and how the overall structure and nesting work. Once you understand these, you're ready to use Emmet to enhance your HTML coding.

Creating a container

You can easily create a container structure like div, main etc by just typing their name in the editor and hitting the enter.

div

will output to

<div></div>

You can create other elements such as lists (ol or ul), nav, header and more without having to type the opening and closing tags manually.

Creating multiple elements using * operator

From manually typing opening and closing tags to just typing the name, we solved one problem. But you might be thinking that it isn’t that useful, as I can type a single element tag easily.

Well, let me ask you to write 5 or 10 div tags. Ok, now you might be agreeing, that now it becomes a problem. Here emmet solves this problem by providing us with asterisk (*) operator.

To write 5 div tags as once, we write the tagname followed by and then the number of times we want it to replicate. e.g. div*5

div*5

will output to:

<div></div>
<div></div>
<div></div>
<div></div>
<div></div>

Just like that 5 div tags were created. Now think about it, if you want to have multiple links using a tags, it becomes so much easier with this simple snippet.

Creating Sibling elements using + operator

In the previous section, we saw an example of how to create multiple elements. However, if you noticed, they were all similar elements, like 5 consecutive div tags.

But what if you need two different tags, one after the other? This is where we use the sibling or plus (+) operator.

To write an h1 tag after a div tag, use the syntax div+h1.

div+h1

will output to:

<div></div>
<h1></h1>

There you go, we have a h1 tag which was created right after the div tag, allowing us to create multiple tags without typing each one manually.

Note: You can combine the asterisk * and the plus + operators to create multiple elements in sequence, like div*2+h1*2.

div*2+h1*2

will output to:

<div></div>
<div></div>
<h1></h1>
<h1></h1>

Now we have 2 div tags which were created followed by 2 h1 tags.

Creating Child Elements using > Operator

So far, we have been creating elements one after another. However, let's say I want to create an unordered list ul with one list item li inside it.

In this case, we can use the > operator, placing the parent tag before the child tag. For example, ul>li.

ul>li

will output to:

<ul>
  <li></li>
</ul>

We can see that Emmet created an unordered list with one list item. Now, let's use the * operator to add 5 list items to the unordered list.

ul>li*5

will output to:

<ul>
   <li></li>
   <li></li>
   <li></li>
   <li></li>
   <li></li>
</ul>

Now we have 5 list elements in an unordered list and this will save us so much time when writing HTML.

However, you can save even more time by automating the numbering inside multiple elements using {$} symbol.

ul>li*3>{Item $}

will output to:

<ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
 </ul>

Isn’t this great for creating items with fast numbering to save some time

Adding Classes and ID Attributes

In real-world development, you rarely use plain HTML tags. You almost always attach a class or an ID for styling. Emmet makes this incredibly fast using the dot . for classes and the hash # for IDs—just like in CSS.

Creating Elements with Classes:

Classes are used for adding the CSS Styles to multiple elements and is done using the class attribute in the HTML tag. To assign a class using emmet we use the dot . operator followed by class name.

To create a div with a class of "container", you just type: div.container.

div.container

will output to:

<div class="container"></div>

There you go we now have a div element with class container added to it.

We can also chain multiple classes by repeatedly using the dot operator followed by the classname.

div.container.mx-auto.p-5

will output to:

 <div class="container mx-auto p-5"></div>

By following this syntax, emmet would create an element like div with multiple class names assigned to it.

Creating Elements with IDs:

IDs in HTML are also used for styling using CSS but is usually done for an unique element on the page. To assign an ID using emmet we use the hash # operator followed by id name.

To create a nav element with an ID of "navbar", type: nav#navbar

nav#navbar

will output to:

<nav id="navbar"></nav>

There you go we now have a nav element with id navbar added to it.

Combining the ID and Classes:

We can even chain the id and class to a single element by adding both hash # and dot . operator to a single element.

div#hero.section

will output to:

<div id="hero" class="section"></div>

See, now we have a div element with id as hero and class as section.

Generating Dummy Text

When creating elements, you might need to add some dummy text for testing how it looks or perhaps you might have heard of lorem ipsum.

Well guess what? Emmet also offers this feature. just type lorem and hit enter!

p>lorem

will output to:

<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit...</p>

You can even specify the word count! lorem10 gives you exactly 10 words.

Combining Everything

Let's put everything we've learned into one single line of code. Imagine you need a navigation bar with a logo, a list of links, and a login button.

nav.navbar>div.logo+ul>li*3>a{Link $}+button.btn-login

will output to:

<nav class="navbar">
    <div class="logo"></div>
    <ul>
        <li><a href="">Link 1</a></li>
        <li><a href="">Link 2</a></li>
        <li><a href="">Link 3</a></li>
    </ul>
    <button class="btn-login"></button>
</nav>

With just one line of Emmet, we scaffolded an entire component!

Conclusion

Emmet is more than just a shortcut tool, it is a fundamental shift in how you write HTML.Once you master these snippets, you won't just be a faster coder; you will be a happier one. You will spend less time wrestling with typos and more time building great things.

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.

1. 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.

2. 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.

3. Lightweight: cURL is a very lightweight software unlike other clients such as chrome or postman.

4. 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.

A Record

This is the most simple and commonly used DNS Record type that we get from the Authoritative Servers. We receive a simple IPv4 address (e.g. 52.74.6.109) from the server.

thatsmanmeet.com.    1    IN    A    52.74.6.109

In the output above, you can see that by running the dig command on my website thatsmanmeet.com, I receive an A record with the IP address 52.74.6.109. This IP address can be used by the web browser to easily give users access to the website.

AAAA Record

AAAA Record or Quad A Record is completely identical to the A Record except instead of the IPV4 address (e.g. 52.74.6.109), it returns an IPV6 address (e.g. 2001:0db8:85a3:0000:0000:8a2e:0370:7334).

IPV6 (Internet Protocol Version 6) is a 128-bit network layer protocol designed to replace the smaller pool of IPV4 addresses on the Internet.

example.com. 1 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

In the output above, you can see that by running the dig command on the website example.com, I get an AAAA record with the IP address 2001:0db8:85a3:0000:0000:8a2e:0370:7334. This IP address can be used by the web browser to easily give users access to the website.

CNAME Record

CNAME (Canonical Name) Record, returns another domain from the authoritative server instead of the IP address.

To understand Cname records, let’s understand a situation. Suppose, you hosted a subdomain (blog.example.com) on a famous service provider and they provided an A record to point the subdomain to the website.

blog.example.com 1 IN A 13.12.4.1

For now, the website was working fine. But let's say there's a major outage on the provider's side, and they set up a new machine. This new machine has the IP address 13.11.4.2. Suddenly, all the websites pointing to the old IP address would stop working. The service provider would have to email all its customers, asking them to update their A records to the new IP address.

This would be very inconvenient, right?

To solve this issue, we have CNAME Records. Let me run the dig command on my subdomain blog.thatsmanmeet.com.

blog.thatsmanmeet.com.    532    IN    CNAME    hashnode.network.
hashnode.network.    1    IN    A    76.76.21.21

In the output above, you can see that my subdomain blog.thatsmanmeet.com returned a CNAME record pointing to hashnode.network. A request was then sent to hashnode.network to resolve my subdomain, and we received an A record from hashnode.network as 76.76.21.21.

Returning to our problem, all I needed to do was add hashnode.network as the CNAME record in my DNS configuration. Even if the IP address changes on Hashnode’s side, my website will continue to work because I have the same CNAME record, and they can map hashnode.network to the new IP address.

subdomain -> Root Servers -> TLD Servers -> Authoritative Servers -> CNAME (domain) 
-> repeat for the CNAME domain -> A IP Address -> Requests to open IP Address

Hence, CNAME records return another domain or alias, which then resolved to the corresponding A record providing the IP address.

NS Records

NS (Name Server) Records tells the resolver that the current domain is now being handled by another authority or the Authoritative server is not the original one.

Let’s say you bought a domain from hostinger and now the flow would look something like:

example.com -> Root Servers -> TLD Servers ->  Authoritative Servers (Hostinger) -> A record

Now for some reason, you decided to delegate the authority of your domain from the Hostinger to Cloudflare, i.e the Domain Registrar still stays the same (Hostinger) but the authority handling it becomes different (Cloudflare).

So, now if you try to do the DNS Resolution, it would look something like:

example.com -> Root Servers -> TLD Servers -> Authoritative Servers (Cloudflare Name Servers)
-> (cloudflare checks internally for the IP of domain example.com) -> Returns A rcord (IP)

Now in case of sub domain, the above authoritative servers can also return CNAME record as well, then again we need to resolve that CNAME record to get the A records.

MX Record

MX (Mail Exchange) Records are used to direct email to a mail server. They specify the mail servers responsible for receiving email on behalf of a domain.

For example, if you have a domain like example.com and you want to handle emails through a specific mail server, you would set up an MX record pointing to that server.

Let's say you want to use Google's mail servers to handle emails for your domain example.com. You would add MX records in your DNS settings like this:

example.com.  3600  IN  MX  1  aspmx.l.google.com.
example.com.  3600  IN  MX  5  alt1.aspmx.l.google.com.
example.com.  3600  IN  MX  5  alt2.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  3600  IN  MX  10  alt4.aspmx.l.google.com.

In this setup, emails sent to any address at example.com will be directed to Google's mail servers. The numbers (1, 5, 10) indicate priority, with lower numbers having higher priority. This means the server with priority 1 will be tried first. If it's unavailable, the next priority server will be used, and so on. This ensures that your emails are reliably delivered even if one server is down.

TXT Records

TXT (Text) Records are used to store text information in the DNS. They can hold various types of data and are often used for verification purposes.

For example, if you need to verify domain ownership with a service like Google Search Console, you might be asked to add a TXT record to your DNS settings. This record would contain a specific string provided by the service.

Let's say Google gives you a verification code to prove you own example.com. You would add a TXT record like this:

example.com.  3600  IN  TXT  "google-site-verification=abc123def456"

In this case, the TXT record contains the verification string. When Google checks your domain, it will look for this record to confirm ownership. TXT records are also used for other purposes, like setting up SPF to prevent email spoofing.

Conclusion

Now you understand why DNS is recursive by nature. It doesn't always hand you an IP address directly; sometimes, it hands you a referral (like a CNAME or NS record), forcing your browser to do the heavy lifting before it finally reaches the destination.

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.

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

1. 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.

2. 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.

3. 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).

4. 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.

1. A user opens the web browser, types the URL (e.g., https://google.com), and presses enter.

2. 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.

3. If the IP address of the website is not found, the DNS query is sent to the Recursive Resolver.

4. 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.

5. If the IP address of the website is not found in the Recursive Resolver’s cache, the request is sent to the Root Servers.

6. 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.

7. 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.

8. 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.

9. The Recursive Resolver returns the response to the browser.

10. 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:

1. Question Section: Contains the query that we sent, In our case to get the IP of google.com

2. 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

3. 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.

Creating a New Git Repository

We begin our Git journey with the command git init. After running this command, we receive confirmation that an empty Git repository has been created.

Initialized empty Git repository in /Users/manmeet/Developer/cohort/inside-git/.git/

This command also creates a hidden .git folder inside our current project folder. To see what's inside this .git folder, we can use the tree command. We get the following structure:

.git
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   └── ... (other sample hooks)
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

Alright, there's a lot in this folder. Let's go through each file and directory one by one to understand what they are.

• config: The config file holds all the settings for the current repository, like the author's information, filemode, and other basic information.

• description: The description file is used only by the GitWeb UI program to display the description of the repository. By default, it holds the content "Unnamed repository..." and can usually be ignored.

• HEAD: The HEAD file contains the reference to the currently used branch, such as main or master. If you look through the contents, it usually contains ref: refs/heads/main, which points to the refs folder that we will cover later on.

• hooks: The hooks folder contains multiple scripts that can be used to perform certain steps automatically before or after Git has performed some operation. The files ending in .sample are disabled by default.

• info/exclude: The exclude file is located at /info/exclude and includes the files that you don’t want to be tracked by Git. However, what makes it different from .gitignore is that this is completely local and is not versioned or pushed to any remote repository. A real-life use case would be if one developer uses a specific tool for testing and wants those specific files excluded from their system only, without affecting the rest of the team.

• objects: The objects folder contains the data about the files, commits, and other information in the form of Git objects. We will cover this further in the blog.

• refs: The refs folder, as the name implies, stores references or pointers to the branches and tags. The folder /refs/heads contains the reference to the latest commits stored on the branch, and /refs/tags stores the references to the latest commit related to that tag.

How Git Works Under the Hood

Let’s create a file hello.txt and create a commit to the main branch. The commands to perform this action are:

echo "hello world" > hello.txt
git add hello.txt 
git commit -m "added hello.txt file"

The commands would create a new file hello.txt with the content "hello world," add it to the staging area, and then commit it to the main branch with the message "added hello.txt file." The output of the commit message is:

[main (root-commit) 9ef19b4] added hello.txt file
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

We can see the history using git log. The output shows the author, time, message, and a unique SHA-1 hash assigned to the commit.

commit 9ef19b4705d268cbdf5906b6e1bdb73f88dc622b (HEAD -> main)
Author: Manmeet <email_address_here>
Date:   Wed Jan 21 00:28:44 2026 +0530

    added hello.txt file

Let’s use the tree command again on that hidden .git folder and see what has changed.

.git
├── COMMIT_EDITMSG
├── config
├── ...
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── main
├── objects
│   ├── 3b
│   │   └── 18e512dba79e4c8300dd08aeb37f8e728b8dad
│   ├── 68
│   │   └── aba62e560c0ebc3396e8ae9335232cd93a3f60
│   ├── 9e
│   │   └── f19b4705d268cbdf5906b6e1bdb73f88dc622b
...
└── refs
    ├── heads
    │   └── main
    └── tags

Observations

1. The objects folder now has multiple subfolders that start with the first two characters of the commit hash. In our commit, the hash was 9ef19b4..., and we can clearly see a folder starting with 9e in the objects folder.

2. The refs folder has also changed, with /refs/heads now containing a main file. If we look at the contents of this /refs/heads/main file, we find the hash of our latest commit 9ef19b4.... It's the same hash that the git log command provided us.

3. A new file COMMIT_EDITMSG contains the last commit message.

Objects Folder

So, now we know that the HEAD file contains a pointer to the branch with the latest commit, which in our case is ref: refs/heads/main. This main file contains the hash of the latest commit, and that commit can be found in the objects folder.

Let's go to the .git/objects folder and list all the files and folders in this directory.

cd .git/objects
ls
# outputs: 3b   68   9e   info   pack

The output of the command above shows several folders with only two characters. These two characters are the first two characters of the hash from the latest commit.

• Latest Commit Hash: 9ef19b4705d268cbdf5906b6e1bdb73f88dc622b

• First two characters: 9e

• Remaining: f19b4705d268cbdf5906b6e1bdb73f88dc622b

So, if we try to go to the folder 9e and print the content of the file f19b4... we get an output that is not easily understandable by us.

cd 9e
ls
cat f19b4705d268cbdf5906b6e1bdb73f88dc622b
# Output: x??A? @Ѯ=???X'?Rz??Nj@c1ho?,{?n...

Just look at the output above. Can you figure out what it means? Yeah, neither can I. This "garbage" text appears because Git compresses the files using zlib to save space. However, luckily, we have a tool called git cat-file that can help us understand the information stored in this file.

Let’s move outside the .git folder and run the command git cat-file -p <latest_commit_hash>:

git cat-file -p 9ef19b4705d268cbdf5906b6e1bdb73f88dc622b

Output:

tree 68aba62e560c0ebc3396e8ae9335232cd93a3f60
author Manmeet <email_address_here> 1768935524 +0530
committer Manmeet <email_address_here> 1768935524 +0530

added hello.txt file

This file contains the exact details of the commit object, including the tree, author, committer, time, and commit message of the latest commit.

What is Tree?

We just saw that on printing the information stored in the latest commit object, there’s some other object called "tree" stored here. Let’s try to use our cat-file command on this git object and see the output.

git cat-file -p 68aba62e560c0ebc3396e8ae9335232cd93a3f60

Output:

100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    hello.txt

From the output, we can see that the tree object contains yet another hash. Now let’s try to cat-file this new hash that was stored by the tree object.

git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

Output:

hello world

This new hash contained the content stored in our hello.txt file, which was "hello world". This is the Blob Object. It contains the actual content of our file.

Hence, a tree object acts like a directory. It maps filenames (like hello.txt) to Blob objects.

Linking Commits: The parent Field

So far, we have only looked at a single commit. But Git is all about history. How does Git know that one commit comes after another?

Let’s modify our file and create a second commit to see what happens.

echo "hello again" >> hello.txt
git add hello.txt
git commit -m "updated hello.txt"

Now, let's check the log to get our new commit hash.

git log --oneline
# Output:
# 8ad32c1 (HEAD -> main) updated hello.txt
# 9ef19b4 added hello.txt file

We have a new commit with the hash starting with 8ad32c. Let's use our trusty git cat-file command to look inside this new commit object.

git cat-file -p 8ad32c1

Output:

tree 42091e6d12345...
parent 9ef19b4705d268cbdf5906b6e1bdb73f88dc622b
author Manmeet <email@example.com> 1768936000 +0530
committer Manmeet <email@example.com> 1768936000 +0530

updated hello.txt

Observation: Notice that there is a new line that wasn't there before: parent.

• The parent field contains the hash of our previous commit (9ef19b4...).

• This "parent" pointer is how Git connects commits together.

If we made a third commit, it would point to 8ad32c as its parent. This chain of parents allows Git to traverse backward through history, from the current state all the way back to the very first commit.

Btw for anyone curious the data structure used here is Linked List.

Conclusion

By following the breadcrumbs, we uncovered how Git stores data:

1. Commit: Stores the metadata (author, time) and points to a Tree.

2. Tree: Stores the directory structure and filenames, pointing to Blobs.

3. Blob: Stores the raw file content.

Now you know what the hidden .git folder contains and how Git organizes and stores data for efficient project management.

This is where I would like to introduce you to PenDrive Analogy.

The Pendrive Analogy

Let’s assume a situation where Alice is working on a codebase. Now while working on the project Alice realises that she might need to take a leave for 3 days due to some work, so she requests her team member Bob to develop a remaining feature for her.

Bob agrees and Alice copies the files from her computer in a pendrive and hands over the pen drive to the Bob and left the office. Bob plugs the pen drive in his computer, copies the code files and start working on the codebase.

While working on the remaining features Bob realises that certain existing part of the code also needs to be changed in order for this feature to work. So, he tweaks certain existing parts of the code as well including deleting a few existing code, but at the end of the day, he achieved the result. He had successfully coded the feature, tested it by running the code and calls it the day!

Three days later, Alice comes back to the office and found the pen drive in the Bob’s cubicle with the note “I’m going on a vacation and I have coded the remaining feature. Tested it and it worked perfectly”. Alice took the pen drive and after few daily office chores, she sits down to work on further tasks on the codebase.

She plugs the pen drive into her computer, copies the code files to her system and opened the code editor, executes the code and found the feature coded by the Bob is working perfectly fine. She was happy to see the feature working but then immediately notices an issue.

Few of the other features that she had worked on earlier are broken and some are not responding well. She switches back to the code editor and…

She Freezes.

Bob has added enormous amount of the code into developing that feature and also have modified the code for some of the previous features. Since, she has replaced the old version of codebase from her computer with Bob’s version, she is now stuck with no way out to know what changes Bob has made to the codebase and how code used to look earlier.

She panics! Asks another team member, if they had the old version of the codebase present on their system. Luckily, she did find it but now she had two versions Accounting_software_old.zip and Accounting_software_new.zip. Now the old one doesn’t have the feature that Bob developed and new one is broken and she needs to show this to the client in upcoming meetings.

She is now stuck playing a game of "Spot the Difference" manually, line by line, while the client meeting clock ticks down. She calls Bob, who is gone on vacation and tells her about the problem. Bob goes to his hotel room, took his laptop out and checks and found some issues, he immediately fixes it but now the problem arises, how to share it back to Alice?

Another issue is that now there exists another version of the codebase with the Bob’s version Accounting_software_new_fixed.zip, which is again an issue. Which codebase will now be considered as source of truth? Alice’s old one? Bob’s feature one? or the one Bob just fixed?

Somehow, Bob saves the day by sending the new code as Email!

Why the Pendrive System Failed

1. The Nightmare of No History (No Undo Button): When Alice replaced her old files with Bob’s new ones, she effectively erased the past. If Bob made a mistake, there was no way to go back to how the code looked yesterday. The past was overwritten forever.

2. The Nightmare of Blindness (No Change Tracking): Alice knew that the code was different, but she couldn't see what was different. She was forced to play a manual game of "Spot the Difference" across thousands of lines of code.

3. The Nightmare of Truth (Source of Truth Problem): By the end of the story, we had Accounting_software_old.zip, Accounting_software_new.zip, and the emailed Accounting_software_new_fixed.zip. Which one is the real project? If Alice fixes a bug in the "Old" one while Bob adds a feature to the "New" one, they have created two separate realities that will be incredibly hard to combine.

This is why version control systems like GIT, SVN, Mercurial etc were created.

How Version Control Systems Solved this Problem

Version Control Systems (VCS) were created specifically to prevent the "Pendrive Panic" we just described.

1. Tracking the Changes: Think of VCS like a CCTV camera for your code. It doesn't just save the file; it tracks every single line that was added, deleted, or changed. You don't just see that the file changed but also what exactky changed.

2. Accountability: In our story, Alice didn't know for sure what Bob touched. VCS tracks exactly who made the change.

3. Ability to Migrate Back: This is the biggest lifesaver. Since VCS saves a snapshot of your project every time you commit, you have an infinite Undo button. If the new code crashes the app, you can instantly roll back to the version from yesterday that was working perfectly.

4. Ability to Work on Multiple Features : This allows Alice and Bob to work in parallel universes. Alice can work on her feature in a separate "branch" without touching Bob's code. They can both code simultaneously without overriding each other's files.

5. Collaboration: No more emailing Zip files. VCS acts as a central hub (like on a server) where everyone syncs their work. It becomes the single source of truth for the whole team.

Conclusion

We learned from the story that version control systems does simplify our lives a lot by tracking changes across entire projects and by providing ability to easily collaborate with others by hosting it on a server, hence solving the traditional pen drive problem.

However, today it's a different story. If I had the ability to go back in time, I would definitely have used GIT.

What is GIT

Git is an open source tool which is used mostly by software developers to track the changes and help in easy collaboration between multiple people across entire projects.

GIT is a Version Control System (VCS). Before we understand what a Version Control System is, first we need to understand what versions are.

Whenever you work on a project, you don’t create it in one shot. You improve it step by step:

• first draft

• small improvement

• new feature

• bug fix

Each meaningful state of the project is a version. In Git, a version is not just “the next file” or “an updated copy”. A version in Git is a snapshot of the entire project at a specific moment in time.

Hence, a version control system is a software that records these snapshots, keep them organised and allow us to move between them easily. Git is one of the widely used version control system.

Why GIT is used?

Git is primarily used for multiple reasons such as:

1. Keeping Track of the changes: As the project grows bigger, manually tracking changes become impossible. However, Git automatically take cares of this problem by keeping a history of every single change done to the project, author who did the changes and when the changes were done.

2. Easy Collaboration with others: Git allows multiple people to work on the same project without constantly sending files back and forth.Platforms like GitHub act as a shared place where people can synchronize their work, review changes, and collaborate efficiently.

3. Allow to work on multiple features at once: Git allows multiple people to work on separate features using the branches and then later merge those features into the main codebase, hence boosting efficiency and development speeds.

Common Terminologies

1. Working Directory: This is the current folder where your codebase is located. It includes all the files and folders you see and work on. It contains all the files tracked, modified, untracked, and ignored by Git.

2. Local Repository: This is the hidden .git folder that contains a snapshot of your entire project.

3. Staging Area: This is where changes made to files in the working directory are stored before saving a snapshot of these changes in the local repository.

4. Remote Repository: A Git repository stored on a remote server or cloud platform like GitHub is called a Remote Repository.

5. Commit: A commit is when you create a new snapshot of changes from the working directory to the local repository through the staging area.

6. Push: The process of moving changes from the local repository to the remote repository is called pushing.

7. Fetch: The process of checking for any new changes from the remote repository is called fetching.

8. Pull: The process of bringing new changes from the remote repository into the local repository and the current working directory is called pulling.

9. Untracked Files: These are the files in the working directory that are not being tracked for changes by Git. In VSCode, they are usually marked with a "U" symbol.

10. Modified Files: These are the files in the working directory that are being tracked and have been modified. They are usually marked with an "M" symbol in VSCode.

11. Added Files: These are files in the working directory that were initially untracked by Git and have been added to the staging area but haven't been committed yet. In VSCode, they are usually marked with an "A" symbol.

12. Deleted Files: These are files in the working directory that are tracked by Git and have been deleted from the working directory. They are usually marked with a "D" symbol in VSCode.

13. Branch: A branch allows you to create a separate line of development, enabling you to work on features or fixes without affecting the main codebase.

14. HEAD: This is a pointer that shows the current branch or commit you are working on in your repository.

GIT Basics: How GIT Works

To understand, how Git works, here’s a diagram from the official GIT website.

1. Initially, you have a project folder or the working directory where no files are being tracked by the GIT.

2. When we run a command git init, it initialize an empty git repository and a new hidden .git folder is created in the same directory.

3. Currently most of the files are still untracked. So, we need to tell the git to start tracking the files and we use git add . command. Once we run this command, then all the files are sent to the Staging Area and the files are now being tracked by the GIT.

4. Once we are satisfied with all the changes, we run the command git commit -m “some message“ and all the changes from the staging area is sent to the local repository, hence creating a snapshot of the entire project.

5. Now at this point, our entire project is being tracked by the GIT.

6. If we make a change in our working directory at this point, either by modifying some file or adding a new file, GIT will immediately notice the files are modified.

7. So, we need to again use git add . command and send the modified files to the staging area and commit them again to save a new snapshot of these changes.

8. By running the command git log, we can see entire history of the commits which includes the hash, author and the commit message.

Common GIT Commands

1. git init: This command creates an new local repository in your current working directory. In other words, this will convert your normal project folder into a git repository.

2. git add: This command allows git to understand which files to track and add them into the staging area. We can add single file like git add hello.txt or all the files using dot symbol like git add .

3. git commit: This command sends the changes from the staging area into the local repository. It also includes a message flag with it like git commit -m “initial commit“.

4. git log: This command shows the entire history of the commits done inside a GIT repository. These logs contain the hash, author, date/time and commit message. There’s also another version of this command that prints shorter logs with —oneline flag. Command becomes git log —oneline.

5. git diff: This command shows the changes between the commits. we can use it like git diff <hash_1> <hash_2> or we can see changes in staging area like git diff —staged.

6. git branch: This command will show all the branches that exists in the current repository. The branch that shows with aestricks (*) like main* is the currently active branch.

7. git pull: This command fetches the latest changes from the remote repository and merges them into the current branch.

8. git push: This command sends your local commits to the remote repository.

Conclusion

GIT is a powerful tool that allows for tracking changes and collaboration with other team members in a much easier way and it’s not even difficult to learn. With only these commands shown in the above section we can achieve 95% of the work in the GIT.

What is Chain of Thought

Chain of Thought is a prompt style that asks the model to break a problem into intermediate steps before giving the final answer. That gentle structure reduces careless mistakes.

Example without CoT

Q: If you have 3 apples and get 2 more, how many do you have?
A: 5

Example with CoT

Q: If you have 3 apples and get 2 more, how many do you have?
A: I start with 3 apples. I add 2 apples. Now I have 5 apples in total. The answer is 5.

Why some models need this

Some models are tuned for short, confident replies. They may skip reasoning, make intuitive guesses, or become inconsistent on multi step problems. CoT acts like scaffolding that guides each step.

A minimal helper for examples

Below is a tiny wrapper you can adapt to your setup. Replace the body with your actual chat call.

async function chatCompletion(prompt) {
  // return await client.responses.create({ input: prompt });
  return "Mocked response for illustration";
}

Basic Chain of Thought prompt

Add a simple instruction like “Think step by step.”

async function chainOfThought(question) {
  const prompt = `${question}
Please think step by step before answering.`;
  const reply = await chatCompletion(prompt);
  console.log(reply);
}

// Example
chainOfThought(
  "A car travels 60 km in 1 hour. How far will it travel in 4 hours?"
);
/*
Expected shape:
First, in 1 hour the car travels 60 km.
In 4 hours that is 60 × 4 = 240 km.
So the answer is 240 km.
*/

Structured reasoning template

Give the model a clear structure to follow.

async function structuredCoT(question) {
  const template = `
Question: ${question}
Step 1: Restate the problem.
Step 2: Identify key facts.
Step 3: Solve step by step.
Step 4: Provide the final answer.`;
  const reply = await chatCompletion(template);
  console.log(reply);
}

// Example
structuredCoT(
  "If a box holds 8 books, how many boxes are needed for 100 books? Return an integer and explain."
);
/*
Expected shape:
Step 1: We need the number of boxes...
Step 2: Each box holds 8 books...
Step 3: 100 ÷ 8 = 12.5 so we need 13 boxes...
Step 4: Final answer: 13.
*/

Few shot plus Chain of Thought

Show one or two worked solutions before the real question. This sets a pattern the model can imitate.

async function fewShotCoT(question) {
  const prompt = `
You will solve problems by explaining your steps briefly, then giving a final answer on a new line starting with "Answer:".

Example 1
Q: I have 5 pencils and buy 3 more. How many in total?
A: I start with 5 pencils. I add 3 pencils. That makes 8 pencils in total.
Answer: 8

Example 2
Q: A bag has 4 apples, and I add 6 more. How many apples now?
A: I start with 4 apples. I add 6 apples. That makes 10 apples in total.
Answer: 10

Now your turn
Q: ${question}
A:`;
  const reply = await chatCompletion(prompt);
  console.log(reply);
}

// Example
fewShotCoT("There are 7 oranges, and I buy 5 more. How many in total?");
/*
Expected shape:
I start with 7 oranges. I add 5 oranges. That makes 12 oranges in total.
Answer: 12
*/

Guardrails for clarity and brevity

CoT can increase length and latency. Keep it tidy with explicit formatting rules.

async function conciseCoT(question) {
  const prompt = `
Solve the following task using at most three short steps, then give a final line starting with "Answer:".
Keep explanations compact.

Task: ${question}`;
  const reply = await chatCompletion(prompt);
  console.log(reply);
}

// Example
conciseCoT("A train moves 90 km per hour for 2.5 hours. How far does it travel?");
/*
Expected shape:
Step 1: Rate is 90 km per hour.
Step 2: Time is 2.5 hours.
Step 3: Distance = 90 × 2.5 = 225 km.
Answer: 225 km
*/

Programmatic checker pattern

Ask the model to propose steps, then verify or recompute the final answer. This can catch slips on arithmetic or logic.

async function proposeVerify(question) {
  const prompt = `
You will solve the problem in two phases.

Phase A Reasoning
Explain your steps briefly.

Phase B Check
Recompute the final value directly and confirm it matches.

Problem: ${question}

Output format:
Reasoning: <two to four short sentences>
Check: <one sentence>
Answer: <final value only>`;
  const reply = await chatCompletion(prompt);
  console.log(reply);
}

// Example
proposeVerify("A recipe needs 3 cups of flour for one batch. How many cups for 7 batches?");
/*
Expected shape:
Reasoning: One batch uses 3 cups. Seven batches require 7 × 3.
Check: 7 × 3 = 21.
Answer: 21
*/

Side by side prompt for learning effect

Use a single prompt that contrasts naive answering with stepwise reasoning.

async function compareNaiveVsCoT(question) {
  const prompt = `
We will answer the same question in two ways.

Naive answer
Just give a direct answer without explanation.

Reasoned answer
Think step by step in two or three short lines, then provide a final line starting with "Answer:".

Question: ${question}

Begin.`;
  const reply = await chatCompletion(prompt);
  console.log(reply);
}

// Example
compareNaiveVsCoT(
  "You have 48 candies and share them equally among 6 friends. How many candies per friend?"
);
/*
Expected shape:
Naive answer: 8
Reasoned answer:
48 candies shared among 6 friends means division.
48 ÷ 6 = 8.
Answer: 8
*/

Practical tips

1. Start with a simple “think step by step” instruction

2. If results are messy, add a structure with labeled steps

3. If the model still struggles, include one or two worked examples

4. Keep explanations concise by setting limits on step count or sentence length

5. Use a final explicit line for the answer so it is easy to parse in code

Summary

Chain of Thought turns a quick guessing model into a steadier reasoner by guiding each step. You do not change the architecture. You just prompt better. Begin with a plain instruction, add structure when needed, and combine with a few examples for tricky tasks.

When interacting with an AI model, you usually set the tone and behavior using a system prompt, it's the invisible guide at the start of each conversation. Think of it as greeting the model with: “You are helpful and concise.” That cue influences how the AI replies. A system prompt can define role, tone, format, or even the rules of the game. For example:

You are an assistant that writes short fairy tales for children.
You answer in friendly, imaginative sentences.

Here, you assign role and style, making sure the AI stays on track. Systems like Microsoft’s have used similar prompts to control the output format and tone.

Zero-Shot Prompting

What it is: You directly ask the model to perform a task no examples provided. It relies entirely on its training and your instruction.

When to use: For simple, well-understood tasks (e.g. translations, summarization, classification)

Code example:

def zero_shot(prompt):
    return chat_completion(f"Classify this as positive or negative: {prompt}")

# Usage
result = zero_shot("I am so happy with this product!")

Why it works: If the model has seen the task in training, it can often do it well even without examples.

Few-Shot Prompting

What it is: You provide a few examples along with instructions. The model imitates the pattern.

When to use: For structured tasks or when precise formatting is needed (e.g. JSON, templated outputs).

Code example:

def few_shot(prompt):
    examples = """
Example 1: Convert to passive voice:
The cat chased the mouse. → The mouse was chased by the cat.

Example 2: Convert to passive voice:
The chef cooked the meal. → The meal was cooked by the chef.

Now convert to passive:
""" + prompt
    return chat_completion(examples)

This helps the model mimic exact transformations because it sees examples first.

Chain-of-Thought Prompting

What it is: You ask the model to show its reasoning step by step. This helps it break down complex tasks.

When to use: For multi-step logic, math problems, or complex decision-making.

Code example:

def chain_of_thought(prompt):
    return chat_completion(f"{prompt} Explain your reasoning step by step.")

# Usage
chain_of_thought("If a train travels 60 miles in one hour, how far in 3 hours?")

Why it works: The model gives intermediate reasoning, which often improves accuracy, especially on reasoning benchmarks.

Persona-Based Prompting

What it is: You ask the model to adopt a persona or role like a teacher, scientist, or storyteller. This can influence tone, vocabulary, and style.

When to use: When you want responses from a specific voice or perspective.

Code example:

def persona_response(prompt):
    role = "You are a kind, patient teacher explaining to a child."
    question = "Explain what a rainbow is."
    return chat_completion(f"{role}\n{question}")

Some research shows that adding a persona may help in certain tasks, but results vary. In some studies, persona-based prompts outperformed Chain-of-Thought and few-shot in reasoning tasks, while others found no real improvement in factual performance when adding social roles.

Bringing It All Together

When you prompt well, the model works better. Here is how the pieces fit:

• System prompt: sets the foundation role, tone, rules.

• Zero-shot: go direct when tasks are simple and clear.

• Few-shot: show examples when you need structure or examples.

• Chain-of-Thought: use for logic or multi-step problems.

• Persona-based: adopt special voice or style, but test its impact.

Imagine a Giant Map of Everything

Think of all the words, pictures, or songs in the world as points on a giant map. On this map, things that are similar are placed closer together, and things that are very different are far apart.

For example:

• “Apple” and “Banana” are close together because they are both fruits.

• “Apple” and “Car” are far apart because they are very different.

That map is what computers use when they turn things into vectors which are just lists of numbers that help the computer know where each thing belongs on the map.

In the image above, we can clearly see that whenever I say "France," the first word that usually comes to mind is "Eiffel Tower." Mom, have you ever wondered why? It's because our minds are good at forming relationships between different words. So, even though France is a country and not a monument, and on the vector map they are kept separate, this is the beauty of vector embeddings. With the help of these maps, we can still infer that there's a connection between "France" and "Eiffel Tower."

Numbers That Capture Meaning

A vector is basically a string of numbers like [0.2, 0.5, 0.8]. At first glance, it looks random but these numbers encode meaning.

For example:

• Words that mean similar things will have vectors that point in similar directions.

• Pictures of cats will have vectors that are closer to each other than pictures of dogs.

The computer doesn’t “understand” like we do, it just notices patterns in the numbers.

Why This Is Useful

When we give a query to a Transformer, It becomes so much easier for a GPT to understand the context of query and how each token are related to one another even if one surface they don’t look the same. With the tokens placed on the vector maps, it is easier to find the relationship between different words hence enabling GPT to provide better outputs as a response.

A Simple Analogy

Imagine you have a box of chocolates. Each chocolate has a tag: flavor, sweetness, color. If you want a chocolate that is similar to your favorite, you just look for chocolates whose tags are close to your favorite chocolate. That’s what vector embeddings do they give each item a “tag” that’s really a bunch of numbers, so the computer can find similar things easily.

Wrapping It Up

So, Mom, vector embeddings are basically a way to turn messy, complicated things; words, pictures, music into numbers so computers can understand similarity. Think of it as a giant invisible map where everything has a spot, and things that are alike naturally cluster together.

What if I told you, this is the same mechanism behind all the AI software that we know and commonly use in our everyday life. So, let’s dive deep into what this process of tokenization is.

Tokenization

Machines unlike humans cannot understand the entire text given to it as an Input as a whole. Machines are more suitable to work and operate with numbers. So, to make the process of working with our human language a lot easier, the query is first tokenized.

Tokenization is a process of breaking down a given query into individual words known as tokens and then converting those tokens into numbers.

Let’s assume we have a sentence like “Hello How are you?”. So this sentence will be broken into individual words known as tokens first.

Tokens : [“Hello“, “ “, “How“, “ “, “are“, “ “, “you“, “?“ , “EOS“]

Here:

• Spaces are tokens as well.

• EOS stands for End of Sequence, marking the end of sentence.

Converting to Numbers

Since, Machines can’t directly work with the tokens, then each of the token is further converted into a hardcoded number. It is a number that have been given to the model during the training phase.

    Hello → "342"
    How → "542"
    are → "2412"
    you → "1412"
    ? → "112"

Now after this process the token list looks something like

Tokens: [342, 542, 2412, 1412, 112, EOS]

Special Characters

Now you might be wondering that in the original tokens array before converting to number, there were also Spaces as tokens. Also what’s that EOS at the end of the array? Well these are Special Characters or Special Tokens.

1. Spaces → Spaces are part of the actual text and hence there could either be a special token associated for spaces or they can be included with the other tokens as well.

2. End of Sequence (EOS) → EOS tells the tokenizer that the query that we have given as an input is now complete or in other words this marks the ending of a sentence, just like full stop in english language.

There are a lot of Special Tokens and different models and tokenizers might have less or more special characters during the tokenization process.

How GPT use tokens?

Well GPT use tokens to help predict the next tokens based on the token it has analyzed so far. It keeps predicting the next tokens until End of Sequence (EOS) is retrieved by the GPT.

User : "The Boy is"
GPT Predicts : "running"
Sequence: "The Boy is running"
GPT Predicts : "fast"
GPT Predicts : "in"
GPT Predicts : "the"
GPT Predicts: "Market"
At last: "The Boy is running fast in the Market " + [EOS]

In short: Tokenization is how AI takes our natural language, slices it into manageable parts, and turns it into numbers hence making it possible for machines to “understand” and respond to us.

Transformers

Transformer by very definition means something that will transform something from one state to another. In other words, it will convert an Input to some another form.

E.g Take example of a Juice Maker Machine. We put the fruits inside the machine and in return we get the juice from the machine. Here, the Juice Machine is working as a Transformer.

So, in simpler words, Transformer takes input and returns output in a desired form. In the Image below the Input of Type A get’s converted to Type B by the Transformer.

Meaning of GPT

So, now that we know what Transformers are, now how does this concept fit into the equation of AI, especially in products like ChatGPT. First let’s understand the word GPT.

In simple terms, GPT stands for Generative Pre-trained Transformer:

1. Generative → It Generates text, numbers etc.

2. Pre-trained → It has been already trained by it’s creator using huge library of text, books, internet articles etc.

3. Transformer → It takes input as previous word and outputs next word.

Now if we look at a product like ChatGPT we can see that the GPT is the real technology, the models that does all the things while the prefix Chat Symbolizes that we can have a conversation with this Transformer.

Now we know that what GPT stands for. Now it’s time to see what is the mechanism behind this awesome technology.

Fancy Next Word Predictor

Let’s take example of the a classroom. We are taught counting when we were kids in the school. So, if I ask you to tell me what would be the next number of 3? You will instantly answer 4. If I ask for next, you will answer 5. Maybe I ask you what comes after A? You will reply B.

Similarly, In another scenario, let’s say I call you on your mobile, what’s the first thing you would say? It will most probably be “Hello?”.

In both of the above examples, we can clearly see that our mind are already trained to predict and tell what would come next and as in above examples, we are fast to reply. Same is the concept and working of the models like GPT.

Hence, all GPT does is it will take previous word, text, number and will predict the next one of either same or different types.

Now, the GPT model will not give the entire output at once. No instead it will output one token at a time and then the same token will be fed as an Input back to the GPT Transformer.

Token could be anything like text, number, letter, word etc. anything that the Transformer can parse and work with. Now, I would be using the word Token instead of words, numbers, etc

So, the output of the Transformer will be fed back into the It again as Input. This process will keep going until the some ending character like <EOF> is encountered.

In ChatGPT, when you say Hello, It will print back “Hi, How are you?”.

Hence in simpler terms, this is how Transformers work. Hence they are nothing but predicting next words just like how your android/iOS keyboard will print next word when typing out.

Hence it’s nothing just a Fancy Next Word Generator.

How GPT Read and Understand Everything You Say

Now, we will learn how a Transformer understands your query by going more low level. It is basically an encoder and decoder and utilize various steps and we will learn all those phases now.

Tokenization → Break the words

When we humans try to understand something we don’t understand the whole sentence as one. Instead we try to understand different words used in the sentence to understand the actual meaning of the thing being said to us. Our brain automatically breaks a big sentence into small chunks and analyze each and every part so we can understand it better.

Similarly, when the Transformer get some Input from the User, the Query will be broken into multiple tokens and each token is assigned a number which is used by the Transformer to further perform some operations, this process is called Tokenization.

Vector Embeddings → Group Tokens by Meaning

When I say the word “Paris”, the first thing that might come to your mind will probably be “Eiffel Tower”, Similarly when I say something like “AI”, then “ChatGPT” might be the first thing that comes to your mind. So our mind has some words that are grouped together by some meaning, which makes it easier for us to relate to something.

Similarly, Transformer would take Tokens and would place them in a Vector Map, which can be 2D or 3D or even have more dimensions where similar meaning words are grouped together. “India” and “France” here are countries, hence they are placed together while “Eiffel Tower” and “India Gate” are monuments and are placed together which makes mapping easier between them.

In large LLMS, these maps are huge with log of dimensions which allow easy relationships between the tokens.

Positional Encoding → Right Token at Right Place

If I say “Hello, how are you?” and “Hello, are you how”, which one makes more sense? Obviously the first one, our brain tries to rearrange certain words in order to make something meaningful. Right? Our brain find meanings in words even by shuffling their positions.

Similarly, Transformers can try to rearrange the tokens based on the numbers assigned to them, so that they are positioned correctly and hence makes more sense and provide a better output for the user.

Semantic Meaning → Right Meaning

If I say “Cat chase the mouse” and “Mouse chase the cat”, if you observe both these sentences have same number of words but the meaning of each sentence is completely different. So, right order is required to make a sense of meaning that feels right.

Similarly, Transformers don’t just look at the position but also tries to understand the meaning between the tokens based on the context. Hence by capturing the semantic meaning we can have the right output of the query given to the Transformer.

Self-Attention → Don’t forget the Neighbors

When you hear a statement like “A Big Bank will not lend money to risky clients”, then how do you know that we are talking about a “Financial Bank” and not a “River Bank”? Well, you will say that because the words “lend money“, “risky clients“ are enough to tell you that we’re not talking about river banks.

Similarly, Transformers checks every token and its neighboring tokens as well to understand how different tokens relate to one another.

SoftMax → What comes next?

I have a small exercise for you. It’s called "complete a sentence." Here’s the sentence: “I’m going to ….” What came to your mind? The market, the gym, or somewhere else? Our brains find many words and choose what feels best.

Transformer does the same thing. When it is on current token it will predict all the tokens that could come next and then based on it would calculate the score into probabilities. The model would then pick the token with the highs probability and the process repeats again.

Multi-Head Attention → More Perspectives

You might be told by many people to think of a situation from different perspectives and Scenarios. It’s usually said, so that you can grasp something much better.

Well Transformer does kinda same thing. It looks at a sentence from multiple angles i.e. different relationships, syntax etc to get a bigger picture.

Temperature → Be Creative Number

If I give you a picture of a school and ask you to write an essay only using what you can see in the picture, then you would be following a rigid instructions and hence the creativity would be highly limited. But what If I told you to just “write an essay on School”. In this case, you don’t have any picture, so everything that comes out would be through your Imagination and it would be lot more creative.

Similarly, Transformers can be told to whether be more creative or more serious when following a prompt. This is done using a setting called as temperature. Hence, the lower the temperature, lesser would be creativity and higher the temperature, the higher will be the creativity.

Summary

In short, GPT is like a supercharged “next-word guesser” with a brain full of books, articles, and conversations. It chops your message into tiny pieces (tokens), figures out what each one means, keeps them in the right order, looks at them from every angle, and then predicts what should come next. Hence by now you now have a good understanding of how GPT works and what is that magic behind all the AI that’s in trend these days.