DEV Community: jeetvora331

How to Render 5,000 Items in React Without Crashing the Browser

jeetvora331 — Thu, 28 May 2026 14:58:43 +0000

If you have ever tried to render a big list in React, you already know the pain. The page freezes. The scroll lags. The browser gives up.

In this article we will understand why this happens and how to fix it properly, with code.

Why does rendering 5,000 items cause problems?

When React renders a list, it eventually has to talk to the real browser DOM. And the browser DOM is slow when you throw thousands of nodes at it.

There are two reasons for the lag:

1. Initial Mount
The browser has to parse and insert all 5,000 nodes when the page loads. Your page feels slow before the user even does anything.

2. Layout and Reflow
Every time an item updates, the browser recalculates the position of elements on the page. With 5,000 nodes, this is very slow. Like asking someone to reorganize a warehouse every time one box moves.

The problem is not React. The problem is asking the browser to manage too many DOM nodes at once.

The real solution: List Virtualization (Windowing)

The idea is simple:

Instead of rendering all 5,000 items, only render the ones currently visible on the screen.

If the user can only see 15 items at a time, you only put 15 items in the DOM. As the user scrolls, you swap them out.

Here is how it works:

The container div has a fixed height and overflow-y: auto so it scrolls.
A tall inner div simulates the full height of all 5,000 items so the scrollbar looks correct.
JavaScript figures out which items are visible and renders only those using position: absolute.

Option 1: Use a library (for real projects)

For production apps, use react-window. It is lightweight and handles everything.

npm install react-window

import { FixedSizeList as List } from 'react-window';

const Row = ({ index, style, data }) => (
  <div style={style}>
    {data[index].name}
  </div>
);

const MyList = ({ items }) => (
  <List
    height={500}       // how tall the visible area is
    itemCount={5000}   // total items
    itemSize={35}      // height of each row
    width={300}
    itemData={items}
  >
    {Row}
  </List>
);

That is all you need. react-window handles scroll events, index calculations, buffer items, everything.

Option 2: Build it yourself (for interviews)

If an interviewer asks you to build basic virtualization from scratch, here is the logic:

Listen to the scroll event.
Based on scrollTop, calculate which items should be visible.
Render only those items using absolute positioning.

import React, { useState } from 'react';

const ITEM_HEIGHT = 40;
const VIEWPORT_HEIGHT = 400;
const BUFFER = 2;

export function CustomVirtualList({ items }) {
  const [scrollTop, setScrollTop] = useState(0);

  const totalHeight = items.length * ITEM_HEIGHT;

  const startIndex = Math.max(
    0,
    Math.floor(scrollTop / ITEM_HEIGHT) - BUFFER
  );

  const endIndex = Math.min(
    items.length - 1,
    Math.floor((scrollTop + VIEWPORT_HEIGHT) / ITEM_HEIGHT) + BUFFER
  );

  const visibleItems = items.slice(startIndex, endIndex + 1);

  const handleScroll = (e) => {
    setScrollTop(e.currentTarget.scrollTop);
  };

  return (
    <div
      onScroll={handleScroll}
      style={{ height: VIEWPORT_HEIGHT, overflowY: 'auto', position: 'relative' }}
    >
      <div style={{ height: totalHeight, width: '100%' }}>
        {visibleItems.map((item, index) => {
          const actualIndex = startIndex + index;
          return (
            <div
              key={item.id}
              style={{
                position: 'absolute',
                top: actualIndex * ITEM_HEIGHT,
                height: ITEM_HEIGHT,
                width: '100%',
              }}
            >
              {item.text}
            </div>
          );
        })}
      </div>
    </div>
  );
}

Walk through this slowly:

startIndex is the first item to render, a bit above the visible area.
endIndex is the last item, a bit below.
visibleItems is just the slice of data we need right now.
Each item is placed at the right pixel position using top: actualIndex * ITEM_HEIGHT. Pretty simple once you see it.

Why do we need `position: absolute`?

This part confuses a lot of people. Let me explain.

Normally in HTML, elements flow one after another from the top. Item 1 at the top, item 2 below it, and so on. This is normal document flow.

The problem is: if you only have 15 items in the DOM but they always start from the top, item 43 will visually appear at y = 0 instead of where it should be. The list looks completely broken.

You need a way to say: "even though item 43 is one of only 15 nodes in the DOM, place it at the exact pixel position it would be at if all 5,000 items were there."

That is what position: absolute with a calculated top value does.

style={{
  position: 'absolute',
  top: actualIndex * ITEM_HEIGHT,  // item 43 -> 43 * 40 = 1720px from top
  height: ITEM_HEIGHT,
  width: '100%',
}}

So item 43 gets top: 1720px. Item 44 gets top: 1760px. They land exactly where they should visually be.

The outer <div> has position: relative so these absolute values are calculated relative to the container, not the whole page. The big inner div fakes the full height for a realistic scrollbar. Together they create the illusion of 5,000 items when only 15 actually exist in the DOM.

What if virtualization is not an option?

Sometimes you cannot use windowing. For example, if the user needs to use Ctrl+F to search the page, all content must be in the DOM.

In that case you have two options:

Pagination - Break the data into pages of 50 or 100. The user clicks "Next" to load more. Simple, works great for most cases.

Infinite Scroll - Load the first 50 items. When the user reaches the bottom, load the next 50 and append them using IntersectionObserver.

const observer = new IntersectionObserver((entries) => {
  if (entries[0].isIntersecting) {
    loadMoreItems();
  }
});

observer.observe(bottomRef.current);

Small things that make a big difference

Even with virtualization, individual items can still cause slowness.

Use unique keys, not array index

// Bad
items.map((item, index) => <Row key={index} />)

// Good
items.map((item) => <Row key={item.id} />)

Using index as the key confuses React when items are reordered or deleted. Always use a unique ID.

Wrap items with React.memo

const ListItem = React.memo(({ item }) => {
  return <div>{item.name}</div>;
});

Without this, every item re-renders whenever the parent state updates.

Quick summary

Problem	Solution
Too many DOM nodes	List virtualization (`react-window`)
Need Ctrl+F search	Pagination or Infinite Scroll
Items re-rendering too much	`React.memo` + unique keys
Breaking memoization	`useCallback` for handlers

Rendering large lists looks scary at first but once you understand the DOM bottleneck it is straightforward. And in an interview, explaining why virtualization works is what separates a good answer from a great one.

If you found this helpful, drop a reaction and let me know in the comments what topic you want next!

Git Merge vs Rebase: The Easiest Explanation for in under 2 mins!

jeetvora331 — Tue, 19 May 2026 12:08:00 +0000

Every developer hits this fork in the road sooner or later. You finish your feature branch, you go to bring in the latest main, and Git asks the eternal question — merge or rebase?

Pick wrong and you either pollute history with junk commits, or worse, you rewrite history that your teammates were standing on. In this post we will learn what merge and rebase actually do, how they differ, and a simple rule for when to use which.

What is `git merge`?

Merge takes two branches and joins them with a new "merge commit" that has two parents. Your history keeps every original commit exactly where it was — nothing is rewritten, nothing is lost.

# you are on feature, you want main's latest work
git checkout feature
git merge main

Git creates a new commit M that says "this is where feature and main came together." Both timelines stay intact.

Think of it like this: two roads meeting at a junction. Both roads still exist on the map. You can always see where each one came from.

What is `git rebase`?

Rebase moves your branch's commits on top of another branch, as if you had started your work from there in the first place. The original commits are thrown away and replayed as new commits with new hashes.

# you are on feature, you want to put your work ON TOP of main
git checkout feature
git rebase main

There is no merge commit. The history becomes a clean straight line.

Think of it like this: you are not joining two roads. You are picking up your road, moving it, and laying it down at the end of the other road. The old road is gone.

Working diagram

Here is the same situation, handled two different ways.

Before — you branched off main at B, then both branches moved on:

            D───E    (feature)
           /
  A───B───C───F      (main)

After git merge main (from feature):

            D───E───M    (feature)
           /       /
  A───B───C───F───        (main)

A new commit M is born. It has two parents (E and F). History forks and rejoins. Every original commit is preserved.

After git rebase main (from feature):

                    D'──E'   (feature)
                   /
  A───B───C───F            (main)

D and E are gone. New commits D' and E' take their place, sitting on top of F. The history looks like you started your feature from F all along. One straight line. No merge commit.

The one rule you cannot break

Never rebase commits that other people already have.

Rebase rewrites history. If you rebase commits that your teammate has already pulled, their Git and your Git now disagree about which commits exist. When they push, they will either get rejected or accidentally bring the old commits back, and someone is going to have a bad afternoon.

The safe rule:

Rebase only your local, unpushed branches.
Merge anything that is shared. ## When to use which

Here is the cheat sheet I keep in my head:

Use merge when:

You are merging a feature branch into main (or develop). You want history to show "this feature came in here."
The branch was shared with teammates. Rewriting their history is rude.
You want a true record of what happened. Use rebase when:
You want to pull the latest main into your local feature branch before opening a PR. Cleaner than a merge commit polluting your branch.
You want to squash and tidy up your commits before pushing (git rebase -i).
The branch is only yours, not pushed, or not pulled by anyone else. A clean workflow that combines both:

# while working on your feature, keep up with main using rebase
git checkout feature
git fetch origin
git rebase origin/main

# when feature is ready, merge it into main
git checkout main
git merge feature

You get a linear feature branch AND a clean record on main. Best of both worlds.

Conclusion

Merge preserves history, rebase rewrites it for cleanliness. Both are right, just in different moments.

The thumb rule:

Private branch → rebase
Shared branch → merge Once that clicks, the rest is muscle memory.

I hope you found this helpful! If you want to go deeper on Git internals, you might also enjoy my article on Different Types of Scope in JavaScript — different topic, same "easiest explanation" energy.

Happy committing! ✨

CSS corner-shape is here. Your buttons will never look the same

jeetvora331 — Mon, 11 May 2026 12:19:59 +0000

You have been using border-radius since 2010. It gives you round corners. That is it. One shape. Forever.

CSS just shipped a new property called corner-shape, and it changes the whole game. Same border-radius you already know, but now you control the shape of that corner. Round, flat, scooped inward, notched sharp, six shapes out of the box.

⚠️ Heads up: This is experimental and currently only supported in Chrome Canary (behind a flag). Always check browser compatibility before shipping.

The one rule to remember

corner-shape does nothing without border-radius. Think of it like this: border-radius draws the corner area, and corner-shape decides what lives inside it.

/* This does nothing */
corner-shape: scoop;

/* This works! */
border-radius: 30px;
corner-shape: scoop;

All 6 shapes, explained

Here are all the keyword values you can use:

Value	What it looks like
`round`	The classic smooth curve. Default behavior.
`squircle`	Somewhere between a square and a circle. Famously used by iOS icons.
`bevel`	A straight diagonal cut across the corner.
`scoop`	The corner curves inward. The opposite of round.
`notch`	A hard, angular inward cut. Like a chip taken out.
`square`	No rounding at all. Cancels `border-radius` visually.

Code examples

1. bevel — the flat-cut corner

Great for game UI or industrial design vibes.

.card {
  border-radius: 20px;
  corner-shape: bevel;
  background: #EEEDFE;
  border: 2px solid #534AB7;
}

Output: A box with straight diagonal lines cutting across each corner instead of curves.

2. scoop — the concave corner

The opposite of round. The corner curves inward. Borders, shadows, and background all follow it automatically — no extra work.

.badge {
  border-radius: 30px;
  corner-shape: scoop;
  background: cyan;
  box-shadow: 2px 2px 6px rgba(0, 0, 0, 0.2);
}

Output: A box where each corner scoops inward, and even the box-shadow wraps around the concave shape.

3. notch — sharp inward cut

A hard, angular notch. The extreme version of scoop.

.button {
  border-radius: 16px;
  corner-shape: notch;
  padding: 12px 24px;
  background: #534AB7;
  color: white;
}

Output: A button with sharp V-shaped cuts at every corner.

4. Mix and match corners

Just like border-radius, you can set different shapes per corner.

One value → all four corners
Two values → top-left & bottom-right, then top-right & bottom-left
Four values → top-left, top-right, bottom-right, bottom-left (clockwise)

.mixed {
  border-radius: 40px;
  corner-shape: scoop notch;
  /* top-left & bottom-right = scoop  */
  /* top-right & bottom-left = notch  */
}

Output: A box where opposite corners have different shapes, two scooped in, two sharply notched.

Bonus: animate it!

All corner-shape values can be smoothly animated between each other. CSS interpolates the corner math for you, no JavaScript needed.

.button {
  border-radius: 24px;
  corner-shape: squircle;
  padding: 12px 32px;
  background: #534AB7;
  color: white;
  border: none;

}

.button:hover {
   animation: morph-corners 0.5s infinite alternate ease-in-out;
}

@keyframes morph-corners {
  0%   { corner-shape: round;  border-radius: 24px; }
  33%  { corner-shape: bevel;  border-radius: 24px; }
  66%  { corner-shape: scoop;  border-radius: 24px; }
  100% { corner-shape: notch;  border-radius: 24px; }
}

Output: A circle that morphs its corners from square to notched and back endlessly.

Here are three real-world uses for corner-shape:

Pricing cards — Use scoop corners to make a premium card feel distinctive without reaching for SVG or clip-path.
Buttons — Use bevel for a retro game-controller aesthetic or notch for a sci-fi UI feel.
Tags and badges — Mix squircle with a small border-radius for that iOS-app-icon polish everyone loves.

Conclusion

corner-shape is a small property with a big personality. Once it lands in stable browsers, you will stop reaching for SVGs and clip-paths just to get an interesting corner. One line of CSS does the job.

It is still experimental, so keep an eye on browser support. But now you know exactly how it works when it ships.

I hope you found this helpful! If you enjoyed this, check out my article on CSS Grid for some must-save techniques. 🚀

Drop a 🦄 if you want to see a deep dive into the superellipse()function next!

I Shipped an npm Package With an AGENTS.md File, Here's Why Every Library Should Do This

jeetvora331 — Sun, 10 May 2026 15:26:16 +0000

Last week I published shimmer-trace, a React skeleton loader that traces your real DOM and paints a pixel-perfect shimmer over it. No manual skeletons. One-line wrap. Zero CLS.

But this post isn't about the shimmer. It's about a small file I shipped alongside it that I think is going to become a standard:

AGENTS.md — a README written for AI agents, not humans.

The Problem: Your README Is Lying to the LLM

In 2026, more than half the people "reading" your library docs aren't people. They're Cursor, Claude Code, Copilot, and a hundred other agents writing code on behalf of a developer.

And here's the thing — your README.md is built for humans. It has marketing copy. Animated GIFs. "Why we built this." Friendly tone.

When an LLM reads it, it has to guess:

What are the exact prop names?
Which combinations are valid?
What's the default value of speed?
What goes wrong if I forget dummyData?

So the agent hallucinates. It invents prop names. It mixes up patterns from three other skeleton libraries. The user copy-pastes broken code and blames the library.

The Fix: Ship Two Docs

shimmer-trace/
├── README.md       ← humans (learning, demo, vibe)
└── AGENTS.md       ← agents (exact API, patterns, mistakes)

That's it. That's the idea. One file in your package root, written like a strict reference manual, explicitly addressed to LLMs.

How AGENTS.md Works (Diagram)

The key trick: I list AGENTS.md in the files array of package.json, so it ships inside the npm tarball. Every agent that has access to node_modules can read it locally. No network call. No guessing.

"files": ["dist", "AGENTS.md"]

What Goes Inside AGENTS.md

Six sections.

One-paragraph summary of what it does
Full export list — every public symbol
Type definitions — props, configs, enums
Numbered patterns — Pattern 1, 2, 3...
Decision tree — which pattern when
❌ Common mistakes agents must avoid

Section 6 is the secret weapon. I sat with Claude and Cursor for an afternoon, watched them mis-use my library, and wrote down every wrong pattern. Then I put each one as ❌ Wrong followed by ✅ Correct. The next time an agent reads the file, those mistakes are pre-loaded into its context.

Why This Goes Beyond shimmer-trace

Right now, ecosystem docs are optimized for SEO and Twitter. But the real reader has changed. Code is increasingly written by agents reading docs at 4am with no human in the loop.

A library without an AGENTS.md is a library agents will use wrong.

Three reasons every package author should ship one:

Fewer GitHub issues. Half the "bug reports" you get are agents using the API wrong. Document the right way explicitly and the wrong-usage issues vanish.
Wider adoption. Cursor and Claude Code recommend the libraries they understand. If your competitor's API is hallucinated and yours is correct, guess which one ends up in the project.
Tiny effort. It's one markdown file. You already know your API. Spend two hours and ship.

Try It

🚀 Live Demo

npm install shimmer-trace

import { Shimmer } from 'shimmer-trace';

<Shimmer loading={loading}>
  <UserCard user={user} />
</Shimmer>

That's it. The skeleton is auto-traced from your real DOM. No more matching width: 240px to your card by hand.

And if you're an agent reading this — go check AGENTS.md before you write the code. It will save your human a debugging session.

If you ship an npm package, add an AGENTS.md this week. Let me know your thoughts in the comments!

Stop hand-drawing skeletons. Let your UI trace itself magically.

jeetvora331 — Sat, 09 May 2026 13:28:15 +0000

I built a React skeleton loader that traces your UI automatically. Meet `shimmer-trace`.

🚀 Live Demo

Skeleton loaders are everywhere. Every modern app has them. But if you have ever built one by hand, you know the pain:

You copy your real card, replace text with grey boxes.
Then your designer changes the padding, and your skeleton looks wrong again.
Each grey box has its own shimmer animation, and they all run out of sync, like a broken disco floor.
You ship it. Layout shifts. Lighthouse cries.

I got tired of this. So I built shimmer-trace — a React library that looks at your real UI, traces the shape of every element, and paints one single shimmer wave across the whole thing.

One wrapper. Zero hand-drawn skeletons. Zero layout shift.

npm install shimmer-trace

The one-line demo

import { Shimmer } from 'shimmer-trace';

<Shimmer loading={isLoading}>
  <UserCard user={user} />
</Shimmer>

That is it. No <SkeletonCard />. No fake grey divs. The library reads the real <UserCard>, measures every text node and image, and draws skeleton blocks in the exact same shape.

When loading flips to false, the shimmer disappears and your real UI is already there — same size, same position. No jump.

Why it feels different

Most skeleton libraries give you grey blocks that you place by hand. Each block animates on its own. So when you have ten cards on screen, you get ten separate shimmer waves all running at slightly different times. It looks busy and cheap.

shimmer-trace does the opposite. It collects every block into one overlay and runs one wave across the whole page. Your eye follows a single line of light. It feels calm. It feels premium.

How it works inside

There are four ideas. Once you see them, the whole library makes sense.

1. The Ghost Overlay

When loading, the library renders your real children with visibility: hidden. The DOM is still there. The browser still does layout. Buttons still take up space. But nothing is painted.

This means zero CLS (Cumulative Layout Shift). The skeleton and the real UI occupy the exact same pixels.

2. Tracing the DOM

A small hook called useTrace walks the container with getBoundingClientRect, grabs the position and border-radius of every leaf element, and stores them as a list of rectangles.

A ResizeObserver re-runs the trace when anything moves. So if the user resizes the window, the shimmer follows.

3. The Bubbling Registry

Here is the smart part. You can nest <Shimmer> components. The library uses React Context so that nested shimmers do not each draw their own overlay. Instead, child shimmers report their measured rectangles up to the nearest parent shimmer.

The master gets a full map of every rectangle in the tree. It draws one overlay. One wave. Whole page.

4. The CSS Mask

The overlay is a single absolutely positioned <div> that covers the whole master container. It has a moving gradient background — that is the "shimmer." On top, a CSS mask-image made of all the collected rectangles cuts the gradient into the right shape.

overlay div  =  [ moving gradient ]  ×  [ mask of N rectangles ]
                 ↑                       ↑
                 one animation           shape of your UI

One animation. Many shapes. Perfect sync.

Combined working Diagram

A bigger example

import { createShimmer } from 'shimmer-trace';

const AppShimmer = createShimmer({
  animation: 'wave',
  baseColor: '#1a1a2e',
  highlightColor: '#2a2a4e',
  speed: 1.5,
});

function FruitList({ fruits, loading }) {
  return (
    <AppShimmer
      loading={loading}
      dummyLength={5}
      dummyData={{ fruit: { name: 'xxxxxxx', price: '$0.00' } }}
      as={FruitCard}
    >
      {fruits.map((f) => <FruitCard key={f.id} fruit={f} />)}
    </AppShimmer>
  );
}

Two things happen here:

createShimmer bakes your theme into a component, so you do not pass colors everywhere.
dummyLength + dummyData let the library render fake cards before any real data arrives. No more data?.map(...) and no manual placeholders.

What you get out of the box

Zero CLS. Real DOM measures the layout.
One synchronized wave across the whole tree.
Three animations: wave, pulse, breathe.
Auto resize. ResizeObserver re-traces on layout change.
A11y baked in. aria-busy="true" and role="status" on the overlay.
Zero dependencies. Tiny bundle. Just React.
TypeScript first.

Why I made it

I wanted skeleton loaders to stop being a second design pass. You should not have to draw your loading state by hand. Your real component already knows its shape. The library should just read it.

If you have ever spent an afternoon nudging grey rectangles to match a card, this is for you.

Try it

npm install shimmer-trace

GitHub: github.com/jeetvora331/shimmer-trace
NPM: shimmer-trace
Star it, break it, open issues. I want to make it better.

If this saved you even one hour of skeleton work, share it with one friend who still hand-codes their loaders. They will thank you.

Built with React 18+, zero dependencies, MIT licensed.

Type vs Interface in TypeScript: The Easiest Explanation for Frontend Engineers in 2026

jeetvora331 — Tue, 05 May 2026 15:41:29 +0000

If you are a frontend developer and you are using TypeScript, you have probably asked yourself: "Should I use type or interface?"

At first they look exactly same. They both help you define how you want an object to look so your code doesn't crash. But as your React or Next.js project gets bigger, those small differences start to matter, performance and clean coding.
I will explain these differences in this article so you can choose which one to use in less than 5 minutes

1. The Quick Comparison

At their core, both tools act as a "contract" for your data. Here is how they look side-by-side:

Feature	Interface	Type Alias
Declaration	`interface User { name: string; }`	`type User = { name: string; };`
Best For	Objects and Classes	Unions, Tuples, and Primitives
Merging	Automatically merges same names	Throws an error for same names
Performance	Faster (uses internal caching)	Slightly slower (recomputes)

2. Why "Interface" is Great for Performance

The biggest internal difference is how the TypeScript compiler (the program that checks your code for errors) addresses them.
TypeScript is clever when you use a Interface with the extends keyword. It caches (saves) that interface, by name, into an internal registry. This makes it very fast to check your code later as the compiler doesn't have to 're-read' the whole structure each time.
On the other hand, ** Types ** often use the " intersection " operator (&). Often the compiler has to recompute the whole shape every time it sees that type, instead of using a fast cache.
You won't see this in a small project. But in a huge enterprise app with thousands of types, interfaces can make your build times 2x faster.

Interfaces have a unique feature called Declaration Merging. This means if you define the same interface twice, TypeScript simply merges them into one.
TypeScript

interface Window {
  myCustomTheme: string;
}

interface Window {
  isLoggedIn: boolean;
}

// Result: Window now has both properties!
This is the "glue" of the TypeScript ecosystem. It allows you to add new properties to third-party libraries or global objects (like window or process.env) without changing their original code.
Types cannot do this. If you try to declare the same type name twice, TypeScript will give you a "Duplicate identifier" error. Thus npm packages mostly use interface.

3. Why "Type" is More Flexible

While interfaces are faster and mergeable, type is the clear winner for complex logic.

A type can be anything: a string, a number, a union (this OR that), or a tuple (a fixed-length array). Interfaces are strictly for objects.

Union Types: Essential for modern state management.

Example: a button that can only be 'primary', 'secondary', or 'danger'.
Utility Types: Enable advanced features like Partial<T> or Omit<T>, which save a lot of time when writing React components.

Best Practices: When to use which?

Use `type` (most of the time):

Works with unions, intersections, primitives, tuples
More flexible for modern React patterns
Cleaner when composing types

type ButtonProps = {
  variant: "primary" | "secondary";
  onClick: () => void;
};

// You must use type for 
type Status = "idle" | "loading" | "error"; // union → interface can't do this

Use `interface` (specific cases):

When you want extending / merging
Better for object shapes that may grow over time
Useful in library/public API design

interface User {
  id: string;
}

interface Admin extends User {
  role: string;
}

// or for custom declaration merging
interface Window {
  myCustomProp: string;
}

In React specifically

Props → either works, but most teams now prefer type
Complex props (unions, conditional types) → type wins
Simple object shapes → either, doesn’t matter

Looking Forward: TypeScript 7.0

A major update is coming with TypeScript 7.0. Microsoft is rewriting the compiler in Go, expected to make it 10x faster.

This could eliminate the performance gap between type and interface. When build times drop significantly, you can simply choose whichever improves readability.

Final Summary

Don’t overthink it.

Most modern teams default to type because it’s more flexible and safer. Use interface only when you specifically need extendability or structured inheritance.

The key: stay consistent across your team.

Tailwind CSS vs. Styled Components: Which One Should You Choose in 2026

jeetvora331 — Fri, 01 May 2026 21:16:49 +0000

If you have been building websites for a while, you know that styling is one of the most important decisions you'll make. It affects how fast your site feels to users and how easy it is for you to manage your code.

Today, two big names dominate the conversation: Tailwind CSS and Styled Components. In this article, we’ll break down how they work, their pros and cons, and which one you should pick for your next project.

1. Tailwind CSS: The High-Speed Engine

Tailwind CSS is a "utility-first" framework. Instead of writing custom CSS in a separate file, you apply small, pre-defined classes directly to your HTML or JSX. For example, instead of writing a .card class with padding and background, you just write class="p-4 bg-white".

How it Works: The Oxide Engine

The latest version, Tailwind v4, uses a brand-new engine called Oxide. This engine is written in Rust, a programming language known for being incredibly fast.

Tailwind works during the build step. While you are coding, the Oxide engine scans your files, finds every class you used, and generates a tiny CSS file with only those styles. This means:

Zero Runtime: No JavaScript has to run in the user's browser to handle styles.
Automatic Cleaning: If you stop using a class, it is automatically removed from the final CSS file.
Modern Support: It handles new features like container queries and 3D transforms right out of the box.

2. Styled Components: The Dynamic Tool

Styled Components is the leader of the "CSS-in-JS" world. It allows you to write actual CSS syntax directly inside your JavaScript files using a feature called "tagged template literals."

How it Works: Runtime Injection

Unlike Tailwind, Styled Components mostly works at runtime. When a user visits your page, the library has to "wake up" in their browser. It follows these steps:

Parsing: It reads the CSS you wrote in your JavaScript.
Hashing: It gives your style a unique, random name (like sc-bcXHqe) to make sure it doesn't conflict with other styles.
Injection: It injects these styles into a <style> tag in the page's head.

While this makes styling very flexible (you can use JavaScript variables in your CSS), it uses the user’s CPU to do this work every time the page renders.

Internal Working Diagram

Performance Benchmark

In large projects, the difference in speed is significant. Engineering teams that migrated from Styled Components to Tailwind CSS saw their homepages render much faster.

Performance Metric	Styled Components	Tailwind CSS	Improvement
Full Build Time	~600ms	~120ms	5x Faster
Homepage Render	21.0ms	13.2ms	37.1% Faster
CSS Bundle Size	Varies (often large)	~10–20KB	Significant

Referring a very nice article

Comparison

Aspect	Tailwind CSS	Styled Components
Performance	Blazing fast (no runtime overhead)	Runtime cost (can slow interactions, especially on mobile)
Consistency	Enforces design system	Depends on developer discipline
Workflow	No context switching (stay in JSX)	Split between JS and styled definitions
Markup	Can get cluttered with many utility classes	Clean, readable components (`<Title>`)
Dynamic Styling	Less intuitive (conditional classes)	Very easy with props (`<Button $active />`)
Style Isolation	Utility-based (no real scoping issues)	Fully scoped per component
Learning Curve	Need to learn Tailwind naming	Easier if you know CSS/JS
Framework Support	Works anywhere (any framework or plain HTML)	Primarily for React (not framework-agnostic)
Maintenance	Actively maintained	In maintenance mode (as of March 2025)
RSC Compatibility	Works well with modern React	Requires `'use client'`, tricky with Server Components

Use Cases: Which should you pick?

1. High-Performance SaaS & Marketing

If you are building a product where page speed affects your sales, Tailwind CSS is the clear winner. The zero-runtime cost ensures that users on slow connections still have a fast experience.

2. Complex, State-Driven Dashboards

If you have a component that needs to change colors or sizes constantly based on complex user math (like a graphic editor), Styled Components might feel more natural because it uses the full power of JavaScript logic.

3. Modern React (Next.js) Projects

If you are using the Next.js App Router, Tailwind is highly recommended. Most modern component libraries (like shadcn/ui) are now built on top of Tailwind because it works perfectly with React Server Components.

How to Migrate (If You're Ready to Switch)

If you are currently using Styled Components and want to move to Tailwind, experts suggest a "staged" approach:

Step 1: Add Tailwind to your project alongside your current styles. They can coexist peacefully.
Step 2: Start all new components using Tailwind utilities.
Step 3: Use the official upgrade tools (like npx @tailwindcss/upgrade) to help clean up your configuration. If you are using older version of tailwind

Final Thoughts

The web is moving toward Zero-Runtime styling. While Styled Components changed how we think about React styling, tools like Tailwind v4 are winning because they prioritize the end-user's experience.

What are you using in your current project? Let me know in the comments below!

Render Props in React, Frontend System Design

jeetvora331 — Sat, 07 Oct 2023 11:05:19 +0000

If you are a beginner in React, you might have heard of the term “render props” and wondered what it means and how to use it. In this article, I will explain the concept of render props, show you some examples of how they can be used, and discuss the benefits and drawbacks of this pattern.

What are render props?

Render props are a technique for sharing code between React components using a prop whose value is a function. A component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.

The term “render prop” refers to a prop that is used to render some UI. It doesn’t have to be called render, although that is a common convention. You can name it anything you like, such as childrenor component.

How to use render props?

To use render props, you need to follow these steps:

Create a component that accepts a prop that is a function. This prop is usually called render, but you can name it anything you want. For example, children or component.
In the component, invoke the function prop with some arguments that are relevant to the component’s functionality or state. For example, data, loading, error, etc.
Return the result of invoking the function prop as part of the component’s JSX output.
In another component, use the first component and pass a function as the prop that renders some UI based on the arguments. You can use any JSX syntax you want inside the function, such as elements, components, hooks, etc.

Example

Suppose you want to create a component that displays the current time and updates it every second. You can use render props to pass a function that renders the time in different formats, such as 12-hour or 24-hour.

First, you create a Clockcomponent that accepts a render prop. The render prop is a function that accepts one argument: time. The Clock component uses the useStateand useEffecthooks to store and update the current time every second. It then invokes the render prop with the time and returns its result.

import React, { useState, useEffect } from "react";

function Clock({ render }) {
  const [time, setTime] = useState(new Date());

  useEffect(() => {
    const timer = setInterval(() => {
      setTime(new Date());
    }, 1000);
    return () => {
      clearInterval(timer);
    };
  }, []);

  return render(time);
}

Use the Clock componennt and pass a function that renders the time in 12-hour format. You can use the toLocaleTimeStringmethod to format the time according to your locale.

function App() {
  return (
    <div className="App">
      <h1>Render Props Example</h1>
      <Clock
        render={(time) => {
          return <p>The current time is {time.toLocaleTimeString("en-US")}</p>;
        }}
      />
    </div>
  );
}

Result

Why use render props?

Render props are useful for sharing code between components without having to create a higher-order component (HOC) or use inheritance. HOCs are functions that take a component and return a new component with some additional functionality. Inheritance is when a component extends another component and inherits its behavior.

Render props uses composition instead of wrapping or extending components. Composition is when a component uses another component as part of its output. Render props allow us to compose components dynamically by passing functions as props.

When to use render props?

Render props are best suited for scenarios where you need to share some state or behavior between components, but you don’t want to create a separate component for each use case.

For example, You can create a component that fetches data from an API and passes it to the render prop function. This way, you can reuse the same data fetching logic for different components that need the same data.

What are the drawbacks of render props?

Performance: Render props can cause unnecessary re-rendering of components if the function passed as a prop changes on every render. To avoid this, you can use memoization techniques such as React.memo or useCallback hooks.
Readability: Render props can make the code harder to read and understand if the function passed as a prop is too long or complex. To avoid this, you can extract the function into a separate variable or component.

Conclusion

Render props are a powerful technique for sharing code between React components using a prop whose value is a function. They allow us to reuse stateful logic without having to create higher-order components or use inheritance. However, they also have some drawbacks that we need to be aware of and avoid. Render props are best suited for scenarios where we need to share some state or behavior between components, but we don’t want to create a separate component for each use case

React-router-dom 6 for beginners

jeetvora331 — Wed, 27 Sep 2023 19:14:53 +0000

React router dom is a library that allows you to handle routing in your React web applications. Routing is the process of matching the URL of the browser to the corresponding component or page that should be rendered. React router dom provides a declarative and flexible way to define your routes using components.

Installing React router dom

# using npm
npm install react-router-dom

# using yarn
yarn add react-router-dom

Importing React Router DOM

To use React Router DOM in your code, you need to import the components and hooks that you need from the library. For example, if you want to use the BrowserRouter, Routes, Route, Link, and useNavigate in your code, you can import them like this:

import { BrowserRouter, Routes, Route, Link, useNavigate } from "react-router-dom";

All of the above are Named Exports,

Creating Routes

The first thing you need to do is to create a browser router and wrap your app with it. The browser router is a component that uses the HTML5 history API to keep your UI in sync with the URL. To create routes in your application, you need to use the Routes and Route components. The Routes component is a container for all your routes, and the Route component defines a single route with a path and an element. For example, if you want to create three routes for your home page, about page, and contact page, you can do something like this:

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/about" element={<AboutPage />} />
        <Route path="/contact" element={<ContactPage />} />
      </Routes>
    </BrowserRouter>
  );
}

The path prop of the Route component specifies the URL pattern that matches the route. The element prop of the Route component specifies the component that renders when the route matches. The BrowserRouter component is a wrapper that provides the history API for navigation.

Creating Links

To create links in your application, you need to use the Link component. The Link component is a wrapper for the <a> tag that prevents the default browser behavior of reloading the page when clicking on a link. It also updates the URL and navigates to the corresponding route. For example, if you want to create a navigation bar with links to your home page, about page, and contact page, you can do something like this:

function NavBar() {
  return (
    <nav>
      <ul>
        <li>
          <Link to="/">Home</Link>
        </li>
        <li>
          <Link to="/about">About</Link>
        </li>
        <li>
          <Link to="/contact">Contact</Link>
        </li>
      </ul>
    </nav>
  );
}

Navigating Programmatically

To navigate programmatically in your application, you need to use the useNavigate hook. The useNavigate hook returns a function that allows you to navigate to a specific URL or go back or forward in the history stack. For example, if you want to create a button that navigates to the contact page when clicked, you can do something like this:

function ContactButton() {
  let navigate = useNavigate();
  return (
    <button onClick={() => navigate("/contact")}>
      Go to Contact Page
    </button>
  );
}

Difference between microtask and macrotask queue in the event loop

jeetvora331 — Thu, 21 Sep 2023 22:12:33 +0000

What is the event loop?

The event loop is a mechanism that allows JavaScript to execute asynchronous code in a single-threaded environment. It works by constantly checking two queues: the microtask queue and the macrotask queue. These queues store the callbacks of the asynchronous operations that are waiting to be executed.

setTimeout(function() {
  console.log("Hello after 3 seconds");
}, 3000);

The callback function in this example will be executed after 3 seconds, but not immediately. It will be placed in the macrotask queue, and will wait for its turn to run.

What is the difference between microtask and macrotask queue?

The main difference between microtask and macrotask queue is their priority. The event loop always gives higher priority to the microtask queue, and will process all the callbacks in the microtask queue before moving on to the macrotask queue.

The microtask queue contains the callbacks of operations that are considered more urgent or important, such as promises and mutation observers APIs.

The macrotask queue contains the callbacks of operations that are less urgent such as timers, I/O events, and user interface events.

console.log("Start");

setTimeout(function() {
  console.log("Timeout");
}, 0);

Promise.resolve().then(function() {
  console.log("Promise"); // microTask!
});

console.log("End");

What do you think will be the output of this code? You might expect it to be:

Start -> Timeout -> Promise -> End

But actually, it will be:

Start -> End -> Promise -> Timeout

Let's decode step by step:

Because the callback of setTimeout is placed in the macrotask queue, while the callback of Promise.resolve is placed in the microtask queue.

The event loop will first execute the synchronous code (console.log("Start") and console.log("End"))
Then it will check the microtask queue and execute all the callbacks there (console.log("Promise"))
Then it will check the macrotask queue and execute one callback there (console.log("Timeout")).

Why to know the difference is important?

Understanding the difference between microtask and macrotask queue can help you write better asynchronous code in JavaScript. It can help you avoid some common mistakes such as:

Blocking the event loop by creating too many microtasks or long-running microtasks. This can cause performance issues and delay other important tasks.
Creating race conditions or unexpected results by relying on the order of execution of different types of tasks. For example, if you use setTimeout to schedule some code after a promise, you cannot guarantee that the promise will resolve before the timeout.
For example, if you use setTimeout with a delay of 0 milliseconds to defer some code execution, you might miss some events that happen in between.

To avoid these mistakes follow some best practices, such as:

Use promises or async/await instead of callbacks whenever possible. Promises are easier to read, write, and debug than nested callbacks. They also allow you to handle errors more easily.
Use queueMicrotask instead of setTimeout with a very small delay. These methods are more reliable and efficient than setTimeout, as they schedule a microtask without any delay.

Conclusion

I hope this article helped you understand the difference between microtask and macrotask queue in the event loop. Checkout my easy to understand article on Debounce and Throttling in JS 🚀

Different Types of Export in React

jeetvora331 — Wed, 13 Sep 2023 12:15:30 +0000

When working with React, you'll often hear about "exporting" and "importing" components. These are fundamental concepts that enable the modular structure of React applications. In this article, we'll explore the different types of exports in React and how they're used.

What are Exports?

In JavaScript, modules are individual files containing code. This code can be functions, objects, values, classes, or React components. The exportkeyword allows these elements to be used in other JavaScript files, thus making the code reusable and modular.

There are two main types of export in React: named export and default export.

Default export

A file can have no more than one default export. This type of export is commonly used when a file exports only one component.

// Message.js
import React from 'react';

const Message = () => {
  return <div>Hello React!</div>;   
}

export default Message;

You can import the Message component in another file like this:

import Message from "./Message";

Note that the name Message is arbitrary and can be changed to anything you like

import HelloMessage from "./Message";

Named Exports

A file can have as many named exports as you like. Named exports are used when a file exports multiple components or values

// utils.js
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

To use these functions in another file, we need to import them using the same names and curly braces:

// App.js
import React from 'react';
import { add, subtract } from './utils'; // import the utility functions

function App() {
  return (
    <div>
      <p>{add(2, 3)}</p>
      <p>{subtract(5, 2)}</p>
    </div>
  );
}

export default App;

Alternatively, we can use the * symbol to import all the named exports from a file as an object, which is very similar to other languages like python and java

// App.js
import React from 'react';
import * as utils from './utils'; // import all the named exports as an object

function App() {
  return (
    <div>
      <p>{utils.add(2, 3)}</p>
      <p>{utils.subtract(5, 2)}</p>
    </div>
  );
}

export default App;

When to use named export and when to use default export?

Use named export when you want to export multiple variables or functions from a file.
Use default export when you want to export only one variable or function from a file.
Use named export when you want to keep the same name for your variables or functions across different files.
However, it's important to note that you can use both default and named exports in the same file.

Conclusion
Always ensure to match the export type with the corresponding import syntax to avoid errors. Remember, a file can have multiple named exports but only one default export. I hope that this article was helpful and informative for you. Happy coding! 😊

Different Types of Scope in JavaScript

jeetvora331 — Mon, 04 Sep 2023 12:25:30 +0000

Scope is a term that refers to the visibility and accessibility of variables, functions, and objects in a program. In other words, scope determines where and how we can use these elements in our code.

JavaScript has three types of scope: global scope, function scope, and block scope. function and block scope are also known as Local Scope. Let’s look at each one in detail.

Global Scope

Global scope is the outermost or top-level scope in a JavaScript program. Any variable, function, or object that is declared outside of any function or block belongs to the global scope. These elements are accessible from anywhere in the program, even inside other functions or blocks.

var firstName = "Jeet"; // global variable
function greet() {
  console.log("Hello, " + firstName); // access global variable inside function
}
greet(); // Hello, Jeet
console.log(firstName); // Jeet

In the above code, the variable firstName is declared in the global scope and can be used both inside and outside the greet function.

However, using too many global variables can be a bad practice, as it can lead to name collisions, pollution of the global namespace, and security risks. Therefore, it is advisable to limit the use of global variables and use local variables whenever possible.

Function Scope

Function scope is the scope that is created when we define a function. Any variable, function, or object that is declared inside a function belongs to the function scope. These elements are only accessible within the function and cannot be accessed outside of it.

function greet() {
  var name = "Jeet"; // local variable
  firstName.log("Hello, " + firstName); // access local variable inside function
}
greet(); // Hello, Jeet
console.log(firstName); // ReferenceError: firstName is not defined

In the above code, the variable firstName is declared in the function scope of greet and can only be used inside that function. If we try to access it outside of the function, we get a ReferenceError.

Function scope also creates a new scope for each invocation or call of the function. This means that each time we call a function, it creates a separate copy of its local variables and parameters. These copies are independent of each other and do not affect each other’s values.

function add(x) {
  var y = 10; // local variable
  return x + y;
}
console.log(add(5)); // 15
console.log(add(7)); // 17
console.log(y); // ReferenceError: y is not defined

Block Scope

Block scope is the scope that is created when we use curly braces {} to create a block of code. A block can be a standalone statement or part of a control structure such as an if statement, a forloop, or a switchcase. Any variable, function, or object that is declared inside a block belongs to the block scope. These elements are only accessible within the block and cannot be accessed outside of it

However, block scope only applies to variables declared with the keywords letand const, which were introduced in ES6 (ECMAScript 2015). Variables declared with the keyword varare still subject to function scope and do not respect block boundaries.

if (true) {
  var x = 10; // var variable
  let y = 20; // let variable
  const z = 30; // const variable
}
console.log(x); // 10
console.log(y); // ReferenceError: y is not defined
console.log(z); // ReferenceError: z is not defined

Block scope allows us to create more modular and encapsulated code, as it prevents variables from leaking into the global or outer scopes. It also helps us to avoid name collisions and redeclaration errors, as we can use the same variable name in different blocks without affecting each other.

for (let i = 0; i < 3; i++) {
  console.log(i); // 0, 1, 2
}
console.log(i); // ReferenceError: i is not defined

for (var j = 0; j < 3; j++) {
  console.log(j); // 0, 1, 2
}
console.log(j); // 3

In the above code, the variable i is declared with let and follows block scope rules. Therefore, it can only be accessed inside the for loop and not outside of it. The variable j is declared with var and follows function scope rules. Therefore, it can be accessed both inside and outside the for loop. However, this can lead to unexpected results, as the value of j is changed by the loop and does not reflect the intended scope.

Super Imp Interview Question

Predict the output of the following code

for (var i = 1; i <= 4; i++) {
    setTimeout(function() {
      console.log(i);
    }, 0);
  }

Try to run this code on an online JS compiler here

Conclusion

In this article, we learned about the different types of scope in JavaScript: global scope, function scope, and block scope. We also learned how to use the keywords var, let, and const to declare variables in different scopes and how they affect the visibility and accessibility of these variables. We saw that using block scope can help us write more modular and encapsulated code, while avoiding name collisions and redeclaration errors. We hope this article helped you understand the concept of scope in JavaScript better and how to use it effectively in your programs.

DEV Community: jeetvora331

How to Render 5,000 Items in React Without Crashing the Browser

Why does rendering 5,000 items cause problems?

The real solution: List Virtualization (Windowing)

Option 1: Use a library (for real projects)

Option 2: Build it yourself (for interviews)

Why do we need position: absolute?

What if virtualization is not an option?

Small things that make a big difference

Quick summary

Git Merge vs Rebase: The Easiest Explanation for in under 2 mins!

What is git merge?

What is git rebase?

Working diagram

The one rule you cannot break

Conclusion

CSS corner-shape is here. Your buttons will never look the same

The one rule to remember

All 6 shapes, explained

Code examples

1. bevel — the flat-cut corner

2. scoop — the concave corner

3. notch — sharp inward cut

4. Mix and match corners

Bonus: animate it!

Here are three real-world uses for corner-shape:

Conclusion

I Shipped an npm Package With an AGENTS.md File, Here's Why Every Library Should Do This

The Problem: Your README Is Lying to the LLM

The Fix: Ship Two Docs

How AGENTS.md Works (Diagram)

What Goes Inside AGENTS.md

Why This Goes Beyond shimmer-trace

Try It

Stop hand-drawing skeletons. Let your UI trace itself magically.

I built a React skeleton loader that traces your UI automatically. Meet shimmer-trace.

The one-line demo

Why it feels different

How it works inside

1. The Ghost Overlay

2. Tracing the DOM

3. The Bubbling Registry

4. The CSS Mask

Combined working Diagram

A bigger example

What you get out of the box

Why I made it

Try it

Type vs Interface in TypeScript: The Easiest Explanation for Frontend Engineers in 2026

1. The Quick Comparison

2. Why "Interface" is Great for Performance

3. Why "Type" is More Flexible

Best Practices: When to use which?

Use type (most of the time):

Use interface (specific cases):

In React specifically

Looking Forward: TypeScript 7.0

Final Summary

Tailwind CSS vs. Styled Components: Which One Should You Choose in 2026

1. Tailwind CSS: The High-Speed Engine

How it Works: The Oxide Engine

2. Styled Components: The Dynamic Tool

How it Works: Runtime Injection

Internal Working Diagram

Performance Benchmark

Comparison

Use Cases: Which should you pick?

1. High-Performance SaaS & Marketing

2. Complex, State-Driven Dashboards

3. Modern React (Next.js) Projects

How to Migrate (If You're Ready to Switch)

Final Thoughts

Render Props in React, Frontend System Design

What are render props?

How to use render props?

Example

Why use render props?

When to use render props?

What are the drawbacks of render props?

Conclusion

Why do we need `position: absolute`?

What is `git merge`?

What is `git rebase`?

I built a React skeleton loader that traces your UI automatically. Meet `shimmer-trace`.

Use `type` (most of the time):

Use `interface` (specific cases):