# Sahil Yadav — Senior Full Stack Software Engineer
> Senior full stack software engineer with 6+ years shipping production products end-to-end at early-stage YC startups (S21, S22, S23). Owns architecture decisions and leads engineers. Currently at Bolto (YC S23). Works across React, Next.js, Node.js, Python, Django, and AWS.
This file contains the full content of sahilten.com — bio, skills, work experience, projects, and every blog post in full — for LLMs and AI tools to read in a single fetch.
## About
Sahil Yadav is a senior full stack engineer who ships end-to-end products at early-stage YC startups — owning everything from frontend and backend to architecture and developer tooling, and leading other engineers. He has driven product builds, large-scale migrations, and internal SDKs, and writes about software engineering, web development, and AI.
- Site: https://www.sahilten.com
- LinkedIn: https://www.linkedin.com/in/sahilyadav10
- GitHub: https://github.com/sahilyadav10
## Skills
- **Frontend:** HTML5, CSS3, JavaScript, React.js, Next.js, TypeScript, Redux
- **Backend:** Node.js, Express, Python, Django
- **Databases:** PostgreSQL, MySQL, MongoDB, DynamoDB
- **Cloud:** EC2, CloudFront, S3, Lambda, API Gateway, Amplify
## Work Experience
### Bolto, YC S23 — Software Engineer
Jun 2025 - Present
- Led the development of the US Payroll product and the 2 senior engineers on it. Wrote an internal SDK that auto-generated backend APIs and types from our spec, cutting boilerplate across every feature.
- Led the migration from SvelteKit to Next.js App Router. Set up the monorepo from scratch and wrote 90% of the new code, including server components, the route structure, and the API layer.
- Rebuilt the data and access layer for multi-tenant companies and multi-role users (worker + company user), redesigning schemas and APIs and adding RBAC at the route and resource level.
- Owned mission-critical features like Autopay from engineering spec to production, iterating on UX without missing deadlines.
- Built two design systems from scratch, one for the core Bolto app, the other for US Payroll. Each has its own component library and design tokens.
- Wrote shared dev tooling (ESLint, TypeScript, and Prettier configs plus Husky pre-commit hooks) as internal packages consumed by every frontend and backend app in the monorepo.
- Integrated authentication with bearer token + cookie support.
- Set up Sentry and PostHog for error tracking and product analytics, with source maps and session replay wired in.
- Wrote a strict Content Security Policy and set up automated dependency vulnerability scans on the repo.
- Helped the team grow, reviewed PRs, fixed engineering processes, and helped with hiring and onboarding.
### Thera, YC S22 — Software Engineer
Mar 2023 - Apr 2025 (2 years 1 month)
- Improved frontend load times by optimizing API responses, reducing payload size by up to 20x and improving Time to Interactive (TTI) across critical user flows.
- Scaled contractor invoicing by building unified views to review, approve, and pay invoices, supporting $500K+ in monthly transactions.
- Led payroll experience development for employees and contractors, enabling multi-role contracts (W2, contractor, EOR) and workflows including onboarding, invoicing, pay stubs, and tax docs.
- Enforced a strict Content Security Policy (CSP), mitigating XSS/clickjacking risks and scoring 100/100 on Mozilla Observatory.
- Integrated Check payroll APIs, powering employee creation, payroll runs, pay stub access, and tax history, enabling 8+ new client onboardings and a new revenue stream.
- Integrated and extended Monite invoicing with custom line items, discounting, and support for PDF and email formats
- Fixed a critical session renewal bug affecting ~7% of onboardings, boosting platform reliability during extended user sessions.
- Improved code quality by enhancing static checks, eliminating the need for Greptile and saving $1K+ annually in dev tooling.
### Novatr, YC S21 — Software Engineer
Jul 2022 - Jan 2023 (7 months)
- Improved mobile performance scores on Lighthouse by 2x through frontend optimization and codebase refactoring, enhancing load times and interaction quality on low-end devices.
- Integrated HubSpot CMS via AWS Amplify, enabling the marketing team to publish content independently, reducing turnaround time and freeing engineers to focus on core product deliveries.
- Redesigned mobile-first, fully responsive learner workflows for tests, assignments, and content, improving engagement and retention across web and mobile.
- Built v3 of the Mentor Management System, delivering responsive dashboards for mentors to manage queries, assignment reviews, and learner progress, streamlining teaching workflows.
### Perceptiviti, Google LPA Startup — Sr. Software Engineer
Feb 2021 - Jul 2022 (1 year 6 months)
- Built multiple products from scratch, including I10 Coder, Sherlock IPA, and a custom-designed Analytics Platform tailored for insurance providers.
- Redesigned and migrated Sherlock AI from Django templates to React CSR, achieving 2x faster load times, improved UI consistency, and better code maintainability.
- Designed and developed the company website end-to-end, delivering a responsive, SEO-optimized experience with a 100% Lighthouse score across performance, SEO, accessibility, and best practices.
- Defined frontend architecture and engineering standards, introducing CI/CD pipelines, scalable guidelines, and best practices to streamline development and deployment.
- Deployed products on AWS CloudFront, cutting hosting costs by 10x and improving availability and latency for global users.
- Engineered a hybrid SSR/CSR architecture using React and Django, optimizing asset delivery with Nginx, reducing file sizes by 3x and improving First Contentful Paint (FCP).
### Stealth — Software Engineer
Jun 2020 - Jan 2021 (8 months)
- Shipped the company's first e-commerce experience end-to-end, launching online sales as a new revenue channel.
- Scaled the storefront on a hybrid static + low-code stack, absorbing 20% MoM order growth with zero dedicated backend.
- Built an internal ops dashboard for catalog, inventory, and order CRUD, replacing manual spreadsheets and cutting fulfillment time for the founding team.
## Projects
### Resto
https://github.com/sahilyadav10/resto
A powerful app for discovering, managing, and rating restaurants. Add, edit, and review dining spots effortlessly — all in one place.
### Quackpolls
https://quackpolls.sahilten.com
A simple and efficient platform for creating, editing, and managing polls. Gather opinions and make decisions faster.
# Blog Posts
## Product-Focused Engineers Win With AI
https://www.sahilten.com/blogs/product-focused-engineers-win-with-ai
Tags: AI, Career, Product · Published: 2026-05-05 · 5 min read
> AI collapses building from weeks to hours, so execution is no longer where engineers stand out. What separates engineers now is product judgment, the calls about how a feature should behave that nobody else is going to make for you. This post is about why that matters more than ever, and how to build the muscle deliberately.
The engineers winning with AI right now aren't the ones who understand how transformers work. They're the ones who understand users.
Building used to take weeks, so being a fast and reliable engineer was enough on its own. You could be the person who shipped clean code on time and that was enough to look good, even if the feature was confusing or hard to use, that was someone else's problem.
AI collapses building to hours. Any engineer can ship a feature fast now. What separates engineers is whether they thought about the person using it.
## Why AI changes the equation
Building used to be the expensive part. A feature took weeks, and once it was out, fixing what you got wrong was its own project that had to fight for roadmap space. AI changes that. Building is cheap now. The hard part is the dozen small decisions that aren't in the spec but determine whether the feature actually works for the person using it.
You might push back here. Isn't AI also getting better at product judgment? Claude can suggest edge cases, draft empty states, flag missing flows. True, and you should use it for that. But AI doesn't know your user. It doesn't know that the person logging in for the first time is a new employee, anxious about whether their account is set up right and their salary will arrive on time. It doesn't know that "No payslips found" reads as broken to someone who's never used the product before. AI can give you ten plausible empty states. You still have to figure out which one is right for the person on the other end.
## What product-focused actually means
Product thinking matters at every stage. What it looks like changes with the company.
It's most obvious at an early stage startup. The ticket is a couple of sentences in Linear and a Slack thread with the founder. It covers the happy path: there's a button, it runs payroll, the employer sees a confirmation. It doesn't cover what happens when an employee hasn't added their bank account yet, or when one of them was terminated last week, or when the payment hasn't gone out yet but the payslip is already showing. Nobody specced these cases because nobody had thought of them yet. You're seeing them because you're the one writing the code, which means you're the one deciding how the product should behave when reality doesn't match the happy path.
It doesn't stop mattering when the company gets bigger and the specs get longer. It just gets harder to notice. A PM at a larger company can spec out the payslip download feature in detail, with a Figma file, acceptance criteria, and a flow diagram. Build it and ship it. Except the file lands in the user's downloads folder as `payslip.pdf`, `payslip(1).pdf`, `payslip(2).pdf`, because the spec said "let users download their payslip" and didn't say anything about the filename. An employee applying for a visa now has to rename three files before they can submit anything. The engineer who thought about where this file ends up names it `Payslip_April_2026_Sahil_Yadav.pdf` from the start. Nobody specced that. It takes two minutes and saves every employee downloading their payslips from doing that work themselves.
That's what product-focused means. Not sitting in roadmap meetings. The judgment calls that land on you because nobody else is going to make them, no matter the company size or how good the spec is.
## How to build this muscle
The good news is that product judgment isn't a personality trait. It's a habit, and the engineers who have it built it the same way anyone builds a habit: deliberately, on purpose, over a lot of features.
**Walls cost the same to build and to remove.** A first-time employer logs in to run payroll. They hit a wall: no bank account on file. They figure out where to add one, add it, come back. They hit another wall: no pay schedule. Off they go again. By the time they actually run payroll, they've context-switched four times and the product feels broken. An engineer who thought about the flow puts an "Add bank account" button right there in the payroll run UI, so the employer can do it without leaving the screen. Same five minutes of work either way, completely different experience for the person on the other end. The spec gets you a feature. Thinking about the user gets you a product.
**Use Claude to find your blind spots.** The user you picture at the start of a feature is usually the only user the feature actually works for. So list out every situation a real user could be in when they hit this flow (onboarding incomplete, compliance pending, data half-filled) and every state the feature itself could be in (empty, loading, error, partial data). Hand Claude both lists and the feature description, and ask what you missed. Claude isn't smarter about your product. It just doesn't share your blind spots.
**Your view of the product isn't the user's.** You built the thing with admin access and the whole flow loaded in your head. They're seeing it for the first time, on mobile, at the end of a long day. Sign up fresh with a new email and run through the full setup with no shortcuts. Or hand the laptop to a teammate who hasn't seen the feature and watch them use it without saying a word. You'll notice everything that's broken in twenty minutes.
**Shipping is when the work starts.** A while back I shipped a major feature. I watched a few users go through it and saw stuff I hadn't thought of, some places they hesitated, some things they expected that weren't there. I patched them that week. If I hadn't watched, those users would still be struggling, and I'd be staring at the support queue trying to figure out what went wrong. So next time you ship something, open session replays and watch a few users go through it. Every place they hesitate or backtrack is a wall you didn't see.
## What this means for you
AI will build whatever you decide. It just won't decide what.
So try this with the next feature you're about to build. Before you write a line of code, write down who's using it, what they're trying to do, and what's standing between them. List the situations they could be in and the UI states the feature could be in, hand both lists to Claude, and ask what you missed.\
Before you ship, run through it yourself with a fresh email or hand it to a teammate.\
And after you ship, watch five people use it. They'll see the obvious problems you stopped noticing weeks ago. Jakob Nielsen's research found that five users is enough to catch around 85% of a flow's usability problems. The number isn't the point. Users hit problems you'd never run into, because they're trying to get something done and you're just trying to verify the code works.
That's the work. AI doesn't do it for you, it just builds whatever you decide on, faster than you ever could yourself. The decision is still the part that matters.
---
## From `any` to Awesome: Demystifying TypeScript Generics (Part 2)
https://www.sahilten.com/blogs/demystifying-typescript-generics-II
Tags: TypeScript, Generics · Published: 2025-06-16 · 5 min read
> You've seen what generics are and how to use them. We'll take it further with example-first dive into constraints, default and conditional types, and how generics power TypeScript's built-in helpers and appear in real-world usage
In Part 1, we saw how generics make your code more flexible and type-safe. We looked at how to define them, why they're better than using `any`, and how they fit into real world functions and components.
Now it's time to go deeper. In this part, we'll explore how to constrain generics using `extends`, provide default types, apply conditional logic with `infer`, and see these patterns show up in React components and API helpers.
By the end, we'll have a clearer grasp of how generics power real code not just as syntax, but as a tool for writing smarter, safer abstractions.
## Can I restrict what `T` can be?
Sometimes `T` is too flexible, and you want to make sure it has certain properties, let's say `length`.
Use `extends` to constrain `T`.
{`
function getLength(item: T): number {
return item.length;
}
`}
This works with anything that has a `length` property:
{`
getLength("hello"); // 5
getLength([1, 2, 3]); // 3
getLength({ length: 10 }); // 10
`}
But fails with types that don't:
{`
getLength(123); // ❌ Error: Argument of type 'number' is not assignable to parameter of type '{ length: number; }'.
`}
You can constrain generics to:
- Specific shapes (e.g. `{ length: number }`)
- Interfaces or types
- Unions of types (e.g. `T extends string | string[]`)
This is especially useful in utility functions where you need flexibility without giving up control over the types.
## Can types change based on conditions?
Yes. Conditional types let you choose one type or another depending on what `T` extends.
{`
type IsString = T extends string ? "yes" : "no";
type A = IsString<"hello">; // "yes"
type B = IsString; // "no"
`}
You'll often see this pattern used to filter parts of a union:
{`
type OnlyStrings = T extends string ? T : never;
type Result = OnlyStrings<"a" | 1 | "b">;
// "a" | "b"
`}
Here's what happens:
- `a` extends `string`, so it's kept
- `1` does not, so it becomes `never`
- `b` extends `string`, so it's kept
## How do generics help with arrays?
Let's say you want a function that returns the first item of an array.
This works, but it throws away type info:
{`
function getFirstItem(arr: any[]) {
return arr[0];
}
`}
It's better with generics:
{`
function getFirstItem(arr: T[]): T {
return arr[0];
}
`}
Now the return type stays in sync with the array contents:
{`
getFirstItem([1, 2, 3]); // number
getFirstItem(["hello", "world"]); // string
getFirstItem([{ id: 1 }, { id: 2 }]); // { id: number }
`}
TypeScript infers `T` from the array's type, no manual annotations needed.
This pattern is behind many array utility functions in libraries. It gives you type safety without extra effort.
## Can I set default generic types?
You can provide a default type so callers don't always need to specify one.
{`
function createSet(): Set {
return new Set();
}
`}
It can be used like this:
{`
const numbers = createSet();
numbers.add(1); // Set
const names = createSet();
names.add("Alice"); // Set
`}
The second call works without passing a type, `T` defaults to `string`.
Use default generics when:
- A specific type is common enough to assume
- You still want flexibility for other cases
## What does `infer` do in generics?
Sometimes you want to extract a part of a type without knowing its name ahead of time. That's where `infer` comes in, it lets you "grab" a type from inside a structure.
Let's take an example:
{`
type GetReturnType = T extends () => infer R ? R : never;
type A = GetReturnType<() => number>; // number
type B = GetReturnType<() => string>; // string
type C = GetReturnType; // never
`}
Here, `infer R` tells TypeScript: "If `T` is a function, extract the return type as `R`."
You don't need to declare `R` elsewhere, `infer` introduces it right in place.
## How do recursive generics work?
You can use generics inside themselves to model recursive structures, like arrays containing more arrays.
{`
type NestedArray = T | NestedArray[];
const input: NestedArray = [1, [2, [3]]];
`}
This tells TypeScript:
A `NestedArray` is either a `number`, or an array of more `NestedArray` values.
You can also model recursive **objects** like this:
{`
type NestedObject = {
[key: string]: T | NestedObject;
};
const data: NestedObject = {
user: {
name: "Alice",
meta: {
role: "admin",
},
},
};
`}
Recursive generics are useful for:
- Deeply nested lists
- JSON structures with unknown depth
- Recursive shapes in APIs or schemas
## Can I use generics in React components?
Yes and you should, especially when your component needs to be reusable but still type-safe.
Let's say you want a `List` component that works with any kind of item. You don't want to hardcode the type, you want the caller to decide.
{`
type ListProps = {
items: T[];
renderItem: (item: T) => React.ReactNode;
};
function List({ items, renderItem }: ListProps) {
return ;
}
`}
Now use it like this:
{`
type User = { id: number; name: string };
const users: User[] = [
{ id: 1, name: "Alice" },
{ id: 2, name: "Bob" },
];
{user.name}}
/>;
`}
No need to annotate the props manually, TypeScript infers `T` from the `items` array.
This keeps your component flexible across different data types while maintaining full type safety.
## How do real projects use generics?
One common use of generics is in HTTP clients. Instead of hardcoding response types or casting manually, you can define a generic wrapper once and reuse it across your codebase.
Here's a simple API utility:
{`
export const request = async (
method: HttpMethod,
url: string,
data?: any,
config?: AxiosRequestConfig
): Promise => {
const response: AxiosResponse = await apiClient.request({
method,
url,
data,
...config,
});
return response.data;
};
export const get = (url: string, config?: AxiosRequestConfig) =>
request("GET", url, undefined, config);
`}
Now when you fetch something:
{`
type UserResponse = { id: number; name: string };
const user = await get("/user");
`}
The response is strongly typed, no need for casting or `any`. You get autocomplete and type safety for free.
## Wrap-up
Generics aren't just for writing flexible code, they help you write precise code. In this post, you saw how to constrain types, add defaults, use conditional logic, and extract deeply nested types with infer.
These tools show up everywhere: in components, utility functions, and API wrappers. Knowing how to use them well makes your code safer, clearer, and easier to scale.
---
## From `any` to Awesome: Demystifying TypeScript Generics (Part 1)
https://www.sahilten.com/blogs/demystifying-typescript-generics-I
Tags: TypeScript, Generics · Published: 2025-06-10 · 3 min read
> TypeScript generics can look mysterious at first, but they’re all about making types flexible and reusable. In this post, we’ll look at what generics really are, how to use them effectively, and when you should define your own.
Ever copied a TypeScript snippet with `` in it, crossed your fingers, and hoped it wouldn’t break things?
You're not alone.
Most of us start our TypeScript journey by ignoring generics altogether. We rely on `any`, or worse, let the type inference engine do all the heavy lifting, until things break in weird, hard-to-debug ways.
But here's the thing: generics aren’t scary once you understand why they exist and how to wield them. In fact, they’re one of the most powerful features TypeScript gives you.
Let's take a practical, example-first dive into generics.
## Why should you even care about generics?
Let’s say you're building a dropdown component. You want it to work with both:
- A list of countries: `['India', 'Japan', 'France']`
- A list of user objects: `[{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }]`
So you write this:
{`
function renderDropdown(items: any[]): void {
items.forEach(item => {
console.log(item);
})
}
`}
This works, but `any` throws away all type safety.
Now, rewrite it with generics:
{`
function renderDropdown(items: T[]): void {
items.forEach(item => {
console.log(item);
})
}
`}
Call it like this:
{`
renderDropdown(['India', 'Germany', 'Canada']);
renderDropdown<{ id: number; name: string }>([
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' },
]);
`}
Now TypeScript knows what each `item` is. Autocomplete and type checking work perfectly.
## What’s `` and do you always need to write it?
`` is a **type variable**, a placeholder.
When you write `function renderDropdown(...)`, you're saying:
> This function takes a type `T`. I don't know what it is yet, but I’ll use it consistently.
But do you always need to write `` yourself?
Not always.
When **calling** a generic function, TypeScript often infers the type:
{`
function identity(value: T): T {
return value;
}
const num = identity(123); // T inferred as number
`}
But in the **function definition**, yes, you must declare ``.
Arrow functions have quirks in TSX files:
{`
// This breaks in TSX because looks like a JSX tag
const identity = (value: T): T => value;
// ✅ Add a comma to tell TypeScript it's a generic, not JSX
const identity = (value: T): T => value;
`}
Use explicit type annotation when:
- Inference fails or gets too vague
- You want to force a specific type
- You're working with constraints or unions
{`
const result = identity('hello');
`}
## Why do you use `T` and not something else?
You can name generics anything: `X`, `Item`, `Banana`.
But by convention:
- `T`: main type
- `U`: second type
- `V`: value
- `R`: return type
- `K`: key
{`
// k extends string | number means keys must be strings or numbers
function mapValues(
obj: Record,
fn: (value: V) => R
): Record {
const result = {} as Record;
return result;
}
`}
Use short names when the intent is obvious. Use descriptive names when clarity matters.
## When should you build your own generics?
Use generics when:
- You're writing reusable functions
- You need to preserve or transform types across parameters/returns
{`
function mergeObjects(a: T, b: U): T & U {
return { ...a, ...b };
}
const result = mergeObjects({ name: "sahil" }, { title: "Chief Button Aligner" });
// result: { name: string; title: string }
`}
Start with concrete types. Reach for generics only when you need flexibility without losing type safety.
## Wrap-up
Generics let you define clear relationships between types, for example, connecting a function’s input to its output. They help TypeScript track and enforce consistent types, especially in cases where type inference alone isn’t enough.
You’ve seen how they work with simple functions, and why `` matters in the first place. In real-world code, though, generics go much further.
In Part 2, we go beyond the basics. You’ll learn how to constrain generic types, set default values, and use conditional logic in type definitions. We’ll also look at how generics help with arrays, objects, and even real-world scenarios like API wrappers and reusable React components, all through example-first explanations.
Stay tuned!
---
## From Request to Render: A Deep‑Dive into Your Browser (Part 4)
https://www.sahilten.com/blogs/a-deep-dive-into-browser-IV
Tags: Browser, Tech · Published: 2025-05-27 · 4 min read
> The browser has parsed HTML, applied CSS, and executed JavaScript. Now, let’s see how it calculates layout, paints pixels, and composes the final visuals on screen.
With structure and style in place, the story starts to unfold.
(Read Part 3 to see how we got here)
The browser takes the scripted DOM and styled elements and starts arranging them spatially: calculating layout, painting each pixel, and layering them with precision.
This is the visual crescendo: where code turns into form, motion, and color.
It’s the final act before the audience sees the outcome.
Let’s walk through how layout, paint, and compositing work together to turn code into pixels.
## - Layout Begins: Calculating Geometry
With the DOM and CSSOM ready, the browser builds the **render tree**. It only includes elements that affect what’s displayed on the screen.
If an element has `display: none`, it’s ignored. But if you use `opacity: 0` or `visibility: hidden`, the element stays in the render tree, it just won’t be visible on screen.
Next comes layout (also known as **reflow**), where the browser figures out the exact size and position of every node in the render tree. It determines whether each element is block or inline, how wide and tall it should be, and where it fits relative to other elements.
This phase is performance-sensitive. When layout-affecting changes, like adjusting width, font-size, or inserting new elements, occur the browser recalculates geometry. Sometimes these updates force other elements to adjust too.
A common pitfall is animating layout-affecting properties like `height`, `top`, `width`, `margin`, etc. Expanding a dropdown by animating its height from `0` to `100px` over `1000ms` might seem harmless, but it forces the browser to reflow and repaint on every animation frame, around 60 times per second, all on the main thread. On heavier pages or low-end devices, this can cause jank or dropped frames.
That doesn’t mean increasing height is always bad. A one-time layout update, like showing a dropdown on click, is fine. The problem is when layout is recalculated continuously during animations.
To avoid that, prefer GPU-friendly properties like `transform` and `opacity`. They don’t trigger reflows and can be composited efficiently without blocking the main thread. For instance, use `transform: scaleY` instead of animating `height`.
### See it Yourself
Open Chrome DevTools > Rendering tab > Enable "**Layout Shift Regions**" to highlight areas recalculated during layout.
## - Paint Club: Painting the Pixels
Once layout settles the size and position of everything, the browser moves on to painting, turning the render tree into actual pixels.
But the browser doesn’t paint directly to the screen. Instead, it paints onto **off-screen buffers called bitmaps**. Each layer gets its own bitmap, and all the visual elements inside that layer are drawn onto it: borders, text, backgrounds, shadows, images, etc.
This step is called **rasterization**: converting styled elements into pixel data. Once rasterized, the bitmap becomes a visual snapshot of that layer, ready to be sent to the GPU for compositing.
Since the browser paints by layers, it doesn’t need to redraw the whole page for every change. Instead, it updates only the bitmaps for the affected layers. This makes minor UI updates much faster.
### See it Yourself
Open Chrome DevTools > Rendering tab > Enable "**Paint flashing**" to highlight areas that get repainted.
## - GPU of Thrones: Compositing Layers
After painting, the browser hands the resulting bitmaps to the **GPU** for **compositing**, the final step where everything gets assembled on screen.
The GPU blends and stacks these painted layers in the correct order, applies transforms like scaling or rotation, and positions them accurately. It doesn’t repaint or reflow anything. It just moves pixels around using already-rasterized content.
Some elements get their own layers by default: `position: fixed`, `
### Wrap-up
Code has become pixels. Your page is now visible (finally)!
In the next and final part, we’ll step backstage and see how browsers schedule all these operations, from networking to rendering, while keeping things smooth, interactive, and fast. Stay tuned!
---
---
## From Request to Render: A Deep‑Dive into Your Browser (Part 3)
https://www.sahilten.com/blogs/a-deep-dive-into-browser-III
Tags: Browser, Tech · Published: 2025-05-20 · 4 min read
> The connection's ready and data is flowing. Let's explore how browsers parse HTML, CSS, and execute JavaScript.
The raw bytes have arrived. The curtain lifts.
(Read Part 2 to see how we got here)
Now the browser begins to perform: parsing HTML, styling with CSS, and breathing life into the page through JavaScript.
It all comes together element by element as the DOM forms the set, CSSOM sets the mood, and JavaScript steps into the spotlight.
Let's break down how structure, style, and interactivity take form in the browser.
## - Inception: HTML Parsing and DOM Construction
The browser doesn't wait for the full HTML response. As the first bytes arrive, parsing begins. The parser breaks down HTML into tokens (tags, attributes, text) and builds a tree called the DOM (Document Object Model).
This parsing happens incrementally. The DOM grows as the stream progresses, which allows for progressive rendering. That's why you often see headers or navbars appear before the full page loads.
But HTML isn't always perfect. If the parser encounters a missing or malformed tag, it doesn't crash. Browsers follow a well defined recovery strategy, injecting missing elements or closing open tags to keep the structure valid. It's part of what makes the web resilient.
One thing that does pause the parser: scripts. When the browser encounters a `