Entire journey of your message in nutshell,

Back in my 5th semester of engineering, I stumbled into a rabbit hole called computer networks. I still remember writing an assignment titled: "What happens when you type Google.com and hit enter?" Spoiler: it wasn't "the page just loads."

The deeper I went, the more ridiculous it got. Layers upon layers of protocols, packets bouncing between servers, networking devices acting like grumpy middlemen, all working together so that I could scroll memes. By the end, I was both stunned and satisfied, thinking, "Ahh, so that's how it actually works."

This blog is me chasing that same curiosity again, but bigger. Instead of just loading a website, we'll follow the entire journey of a message. From text to bits, bits to signals, and signals to waves. We'll peek into everything that quietly joins the relay: the software, the operating system, memory, CPU, the network stack, communication systems, RF, antennas, and all the unsung heroes in between.

Each step will be its own chapter. Together, they'll tell the full story of what really happens after you tap Send. Because behind that tiny button lies an entire universe of engineering that most people never notice, but once you do, you can't unsee it.

Let's start with…

Chapter 1: From HTML to Front-end, Front-end to HTML

Before going thorugh all fancy detail let's undertand how (web)apps are built. In this first chapter, I will explore the Front-end part of the messaging app.

Whenever you want to message someone, you can open your favorite messaging app, which may look like this.

There are too many things going on here, but let's just focus on messaging someone. Then you jump to DM of that person to type the message. Then you see something like this.

At a high level, everybody knows it is an input text box with a send button. It is the thing that holds our message until you press the send button. But how ? To answer that, let's explore how we arrived here.

The app you use could be a desktop app, a mobile app, or a web app.
Here, we'll focus on the web app, which runs inside your browser because, in reality, most desktop and mobile apps are just wrappers around a browser.

A typical web app is made up of several parts: Frontend, Backend, Security, Networking, and more. But let's zoom in on the Frontend, the part you directly see and interact with. Simply put, the Frontend is a piece of code fetched from a server and executed natively in your browser(mostly).
This code is usually written in HTML, CSS, and JavaScript.

However, modern web apps (like chat or messaging platforms) aren't just written with plain HTML, CSS, and JS anymore. Today, developers use a wide variety of frameworks, libraries, and tools to build complex, efficient, and dynamic user interfaces.

🕰 A Bit of History

In the early days of the web, the frontend was very simple, just static HTML and CSS. Even early messaging apps used nothing more than a basic HTML form and a server-side script to send and display messages.

The server would generate new HTML every time, showing all the messages again. As browsers evolved, so did the frontend. What used to be a simple web page has now become a full-fledged web application, interactive, real-time, and rich in user experience.

If we tried to build something like Discord using only plain HTML, CSS, and vanilla JS, it would take a huge amount of time and effort.
So, many developers decided to spend their time creating frameworks — tools that saves others time and make it easier for others to build amazing web apps. That's how modern frontend frameworks came into existence and continue to evolve today.

Let's understand the framework in general.

Let's understand what a framework really means. A framework is a pre-built structure with defined rules that provides a foundation for building applications. It controls the flow and architecture of your project so you can focus on implementing specific features instead of reinventing everything from scratch.

That's the textbook definition — but it still feels a bit abstract, right?
So, let's make it simple with an example.

🏠 The House-Building Analogy

Imagine you're a new contractor building houses.
If you start without any framework or blueprint, you'll have to do everything manually bake your own bricks, collect sand, craft windows and doors, lay down plumbing and electrical lines all by yourself. You decide and design every single detail. That's an enormous amount of work.

Now, as you gain experience, you create a blueprint a structured plan that defines how a house should be built. It includes details like where to buy materials, how to lay the foundation, how plumbing and electrical should connect, and more. With this blueprint, you no longer need to worry about the tiny repetitive tasks. You can now focus on designing and decorating the house in your own unique style.

Even better thousands of other contractors can use that same blueprint to build houses of different styles, while still following the same rules and structure.

In the world of software, a framework works just like that blueprint. It provides a ready-made foundation with rules and best practices already in place. You simply build your app on top of it focusing on your own features, logic, and creativity while the framework handles the underlying structure and flow. Some of the popular Front-end frameworks are React, Angular, VueJS, Svelte.

Let's explore one of the most used framework: React

This is not going to be a tutorial, just a simple description of the folder structure and rules.

This is what the folder structure looks like when you create a React app using npx create-react-app.

The most important part of this framework is the node_modules folder. This folder contains React libraries, build tools, developer tools, and dependencies. Libraries are imported, and the project is written. Build tools used to build and run the project. Developer tools are used for testing and debugging.

But why is it called node_modules?
It is because the tools inside the node_modules folder are scripts written in JavaScript, which run on Node.js, a runtime environment outside the browser, and are managed by NPM (Node Package Manager).

The public folder is the root folder of the framework cause it contains index.html, which is the entry point of your application. It also has a static asset, which is bypassed by the build tools. We will discuss this further in the build section.

The src folder (source folder) is the core directory in a React application where most of your development work happens.

Above is an example of content inside the src folder. The content in the src folder includes a variety of elements such as components, pages, hooks, services, and CSS. JSX, which is a syntax extension for JavaScript, lets you write HTML-like code right within your JavaScript files[Rules]. It's widely used with React to define how the user interface should appear.

Understanding package.json is super simple when you think of it as your project's blueprint. This JSON file outlines everything from the project's identity and version to its dependencies and beyond. Developers can easily tweak this file to make any necessary adjustments in the framework.

The package-lock.json file is a crucial component for anyone looking to maintain or share a project. Much like the package.json file, it keeps track of the dependencies used in your project. However, the key difference is that package-lock.json locks in the exact versions of those dependencies.

Imagine you've worked on a project and, after a year, decide to share it with a friend. During that time, the dependencies might have been updated. If your friend runs npm install, they could end up with newer versions that might not play nicely with your project. That's where package-lock.json comes to the rescue, ensuring that the precise versions of the dependencies you need are installed.

Front-end to plain HTML

We all know that browsers primarily understand HTML, CSS, and JavaScript. However, when you dive into a framework, you encounter a whole suite of tools, libraries, and files that go beyond just those three. For instance, React often uses JSX, which is a bit different from standard HTML. Plus, you'll find a bunch of other files involved. So, how do we transform and bundle everything into a format that browsers can easily understand, like HTML? That's where the magic of build tools comes into play!

Before we jump straight into the building process, let's take a moment to explore what build tools are all about, using a bit of foundational knowledge.

Build tools

When you're diving into C programming and save your code as main.c, you'll need a C compiler to turn that into an executable file. But here's the catch, if you've included another file in your main.c, you'll have to let the compiler know about it for both compilation and linking. Imagine working on a big C project with tons of files and modules; having to specify each one every time you run the project would be a serious hassle. That's where CMake comes in to save the day! This handy build tool allows you to write a script that automates the process, compiling multiple files into a single executable. It's all about making your life easier and streamlining the final product.

Now, if we shift gears to the world of React, we have build tools like Webpack and Babel doing a similar job. There are also other options out there, like Vite, but the end goal remains the same. Among these, Babel and Webpack are the most popular combo for React projects. So, let's dive into how these build tools transform a simple React project into something that browsers can easily understand!

Let's start with JSX file, which contains the input box and send button.

import { useState } from "react";

export default function MessageInput() {
  const [text, setText] = useState("");

  const handleSend = () => {
    if (!text.trim()) return;
    console.log("Sent:", text);
    setText("");
  };

  return (
    <div className="flex gap-2 items-center">
      <input
        type="text"
        value={text}
        onChange={(e) => setText(e.target.value)}
        placeholder="Type your message..."
        className="border rounded px-3 py-2 flex-1"
      />

      <button
        onClick={handleSend}
        className="bg-blue-500 text-white px-4 py-2 rounded"
      >
        Send
      </button>
    </div>
  );
}

So, the build process kicks off when you type in npm run build. Basically, you're giving a heads-up to Webpack and Babel to grab all the source code from your project, especially what's in the src/ folder, and get it ready for the browser. The very first thing that happens is converting all that modern JS and JSX into good old plain JavaScript, and that's all thanks to Babel! Babel is often referred as transpiler that convert the Modern Javascript to most widely used format even supported by old browsers.

Once that's done, the bundler(Webpack) gets to work. The starting point for Webpack is the index.js file, which is a staple in every React project found in the src folder. It's "RULE" to have it there! This file imports App from /App and Webpack takes care of resolving that along with other imports. It also handles any CSS imports inside App.jsx. Now, if you're dealing with a large project, Webpack builds a dependency graph to sort through all the imports and combines all the JavaScript into one file and the CSS into another. How neat is that?

After bundling the JS and CSS, it is time to build the HTML file. There is an index.html file inside a public folder. Having a div tag with the class name root.

<!DOCTYPE  html>
<html  lang="en">
<head>
<meta  charset="UTF-8"><meta  name="viewport"  content="width=device-width, initial-scale=1.0">
<title>React Build Example</title>
</head>
<body>
<div  class="root"></div>
</body>
</html>

Webpack injects the script and CSS link to this file and place it inside the build folder.

After all the compressing and building of the project, you'll end up with a separate folder called the build folder. This folder contains all the combined and bundled files, including static files in plain HTML, CSS, JS, and media files. You can think of this folder as the result of manually building a project using HTML, CSS, and JS, but it's all generated automatically by build tools.

<!DOCTYPE  html>
<html  lang="en">
<head>
<meta  charset="UTF-8">
<meta  name="viewport"  content="width=device-width, initial-scale=1.0">
<title>React Build Example</title>
<link  rel="stylesheet"  href="static/css/main.f855e6bc.css">
</head>
<body>
<div  class="root"></div>
<link  rel="stylesheet"  href="static/js/main.abc123.js">
</body>
</html>

And the file(index.html) inside build folder is browser-ready which is served by the web server if the request is made.

Have you ever thought about why we call it index.html and why it's such a big deal? If you've ever tried to deploy your website on platforms like Netlify, GitHub Pages, or Vercel, you know you need that index.html file. Without it, you might run into some errors during deployment or even end up with a frustrating 404 message on your site. Here's the story behind it: When Tim Berners-Lee developed the first web server and browser at CERN, websites were essentially just folders packed with HTML files. To simplify navigation, web servers needed a default file to display when someone visited a directory, rather than leaving them staring at a blank page or a confusing list of files. That's where index.html comes in, it's like the main page or table of contents for that folder. As the internet evolved, modern web servers kept this convention, always on the lookout for index.html. So, when you type in xyz.com without specifying a file or page in the URL, the web server automatically searches for index.html. This file serves as the homepage or entry point for the site, making it the go-to file that gets served up by default. Pretty neat, right?

Now the browser loads the index.html file, downloads the linked CSS and JS file, runs the JS file, and then the App is rendered. But hold on, there's more to the story! Remember how we mentioned that Babel transforms JSX into plain old JavaScript? Well, that's still not quite ready for rendering as an HTML element. So, how do we make that happen?

It all boils down to the DOM, which stands for Document Object Model. We'll dive deeper into that in the next blog post, but for now, just think of the DOM as the tree structure that represents every element on a webpage.

This DOM tree can be modified by JS. Thus, we can create more dynamic elements with JS itself. What React brings to the table is the concept of a virtual DOM, where it organizes a hierarchy of HTML elements in a JSON format.

In the index.js file, the line ReactDOM.createRoot(document.getElementById("root")).render(<App />); serves as a crucial link between the real DOM and the virtual DOM. Essentially, the DOM acts as a representation of the HTML structure within your application.

The concept of the Virtual DOM in react has it separate story and it is reason why web apps are much faster and smoother. If you want to learn more about this refer this [link].

To wrap things up, this chapter provides a general overview of the frontend specifically focusing on how our input text box and send button are coded and constructed for browsers. In the next chapter, we'll dive into the world of browsers, exploring how HTML is rendered on the screen, and ultimately address the question of how we arrived at this point.