DEV Community: Jacopo Carosi (TheEdgeOfDev)

Web Request Journey

Jacopo Carosi (TheEdgeOfDev) — Mon, 23 Jun 2025 00:00:00 +0000

Considering that Front-end developers constantly work with concepts like lazy loading and asynchronous requests, they rarely take the time to consider
what is really happening behind the scenes of the Web.

So, I decided to summarize the journey that a data packet usually takes from a client to a server, step by step.

Note: This article is not meant to replace deep foundational knowledge like the OSI model or TCP/IP model, which are covered in specialized courses.
Rather, the article aims to be a conceptual map to get a high-level understanding of the main actors involved when we send a request to a server and receive a response.

Starting from the Browser

Everything begins on your computer or mobile device the moment you open your favorite browser (Firefox, Chrome, Safari).

You type a URL (e.g., www.example.com) into the address bar or click on a link that opens a web page.

Now the Browser performs several checks on various caches:

Browser Cache Check: first, it checks its local cache to see if the page (or parts of it like images, CSS, JavaScript) was already downloaded and hasn't expired. If it finds a valid version it will use that, significantly speeding up load time.
Browser DNS Cache: checks if the IP address is in the browser's DNS cache.
Operating System DNS Cache: if not in the browser, it checks the OS DNS cache.
Local Router Cache: may have its own DNS cache.

If none of the caches (or only part of them) can generate 100% of the page, it moves to the following steps:

DNS Resolution (Domain Name System): if the page isn't cached or the IP is unknown, the browser must translate the domain name (e.g., www.example.com) into a numeric IP address (e.g., 93.184.216.34). It does so by querying the Internet Service Provider's DNS servers.
Authoritative/Root DNS Servers: if the ISP doesn't know the domain, it queries higher-level DNS servers until it finds the authoritative server for that domain, which returns the correct IP.
Establishing TCP/IP Connection: once the IP is obtained, the Browser establishes a connection with the server. Most web traffic uses the TCP (Transmission Control Protocol). This happens via a process called the "Three-Way Handshake":

SYN: browser sends a SYN (synchronize) packet to initiate a connection.
SYN-ACK: server responds with a SYN-ACK (synchronize-acknowledge) packet.
ACK: browser responds with an ACK (acknowledge) packet. Now the connection is established! 🤝

TLS/SSL Handshake (for HTTPS): if the URL starts with https://, a secure connection is required. After the TCP handshake, a TLS/SSL Handshake occurs to encrypt the exchanged data. Browser and server exchange messages to verify the server's identity via SSL/TLS certificate, agree on encryption algorithms, and generate secret session keys.

This ensures the data is unreadable to anyone intercepting it (in theory).
Sending the HTTP Request: now the Browser sends the actual HTTP request, which includes:

HTTP Method: GET, POST, PUT, DELETE, etc.
Path: specific resource being requested (e.g., /page.html, /api/users).
HTTP Protocol Version: (e.g., HTTP/1.1, HTTP/2, HTTP/3).
Headers: extra info like browser type (User-Agent), accepted content types (Accept), cookies, etc.
Body: optional, mainly for POST or PUT to send data (e.g., form input).

Go to full article

Vintage Lazy loading

Jacopo Carosi (TheEdgeOfDev) — Mon, 12 May 2025 00:00:00 +0000

Summary

In this tutorial, I will show how I implemented an handmade lazy loading for a project where I was not able to use the modern solutions that we know well. Be aware: this is not a best practice or a solution as we usually intend, but a workaround that I found in one of my jobs.

Go to full article

JavaScript Traps

Jacopo Carosi (TheEdgeOfDev) — Wed, 16 Apr 2025 00:00:00 +0000

Why is JavaScript Full of Pitfalls?

I’ve never loved LeetCode and coding quizzes; I always saw them as a specialization in our field, in light of the fact that it is a mix of mindset and training. And in fact, not all developers are good at programming quizzes, me included.

But recently, speaking with a friend about these kinds of tests, I found myself having to explain why JavaScript, unlike other languages, requires a more cautious and informed approach right from the basics when you want to test yourself and OMG…

Go to full article

Clean CSS Architecture

Jacopo Carosi (TheEdgeOfDev) — Fri, 28 Mar 2025 00:00:00 +0000

CSS defines how things should appear on the screen, not how to calculate or execute them.

Summary

In this article, I intend to explore in depth a question that many Front-end developers know well: why CSS is so often a source of frustration and skepticism.

I won’t just retrace its historical problems, but I want to delve into what I consider the fundamental misunderstanding of CSS: the idea that key concepts like the cascade algorithm and specificity are design flaws to be circumvented, perhaps by resorting to frameworks, rather than true foundational features of the language.

To learn to appreciate CSS, I believe it’s essential first and foremost to accept the mechanisms that govern it, from the box model to display, passing through the cascade, and to learn to use them consciously. Only then we can apply the indispensable order and discipline to the structure of our code, aiming to create stylesheets that are not only functional, but above all scalable and with predictable behavior.

Precisely with this goal in mind, towards the conclusion of the article I will present my solution: the Clean CSS Architecture. Inspired by the basic principles of Design Systems and some concepts from Clean Architecture, this proposal of mine offers a structured approach that allows using the intrinsic principles of the cascade in a controlled and predictable way, thus transforming what many see as a weakness into a strength for code maintainability.

Go to full article