Forem: Shubhra Pokhariya

Lighthouse Said It Was Fast. My Users Kept Clicking the Same Button.

Shubhra Pokhariya — Wed, 06 May 2026 09:46:33 +0000

The bug wasn’t performance. It was silence.

I ran into this while building a Next.js dashboard.

There was a button that triggered a report generation flow. Some client-side processing, then an API call.

Lighthouse looked great. API response was around 80ms.

But session recordings told a different story.

Users were clicking the button 3 to 5 times in a row.

No errors in logs. No failed requests. Everything technically worked.

So I watched one of the recordings more carefully.

The moment the user clicked, nothing changed on screen.

No loading state.
No disabled button.
No visual feedback at all.

The UI looked exactly the same before and after the click.

That was the issue.

80ms response, zero perceived response

The backend was fast.

The interface just didn’t acknowledge the interaction.

From the user’s point of view, the click didn’t go through.

So they clicked again.

And again.

Not because they were impatient. Because the UI stayed silent.

Where most of us focus (and where it falls short)

We spend a lot of time optimizing load performance.

FCP, LCP, bundle size, Lighthouse scores. All worth caring about.

But most of the time a user spends on your app happens after the page has loaded.

That’s where trust is decided. In the interactions.

The 200ms line

There’s a threshold that shows up consistently in real usage.

If the UI responds within roughly 100 to 200ms, it feels instant.

Between 200 and 500ms, the delay becomes noticeable.

Beyond that, people start questioning whether their action worked.

A slow app is frustrating. An app that feels unresponsive gets abandoned.

What INP actually measures

INP (Interaction to Next Paint) focuses on one thing:

How long it takes for the user to see a response after they interact.

Not when your API returns.
Not when your function finishes.

When something visibly changes on the screen.

That’s what closes the loop.

The fix was not “make it faster”

The fix was: acknowledge the interaction immediately.

Instead of doing all the work first:

button.addEventListener("click", async () => {
  await processData();
  await syncWithServer();
  setLoading(false);
});

Flip it:

button.addEventListener("click", async () => {
  setLoading(true); // immediate visual feedback

  await scheduler.yield(); // let the browser paint

  await processData();
  await scheduler.yield();

  await syncWithServer();

  setLoading(false);
});

If scheduler.yield() is not available yet in your environment, a simple fallback works:

const yieldToMain = () => new Promise((r) => setTimeout(r, 0));

Same total work. Same total time.

Completely different experience.

Users stopped clicking multiple times.

The pattern you already use

You’ve seen this in every modern app.

You tap like. It updates instantly. The server confirms later.

That’s optimistic UI.

Here is the same idea in a simple form:

async function handleLike(postId) {
  setLiked(true);
  setCount((c) => c + 1);

  try {
    await api.like(postId);
  } catch {
    setLiked(false);
    setCount((c) => c - 1);
  }
}

In React and Next.js setups, this maps cleanly to useOptimistic and Server Actions.

The idea stays the same:

Show the result immediately. Reconcile in the background.

Why this matters more than Lighthouse 100

Lighthouse runs in controlled conditions.

Your users don’t.

They’re on slower devices, switching tabs, running background apps, dealing with network jitter.

You can ship a perfect score and still have interactions that feel off.

INP exposes that gap.

If you want to go deeper

This bug was the entry point for me.

I ended up breaking this down properly across INP, optimistic UI, task yielding, and how this fits into modern Next.js setups like Server Actions and streaming.

I wrote it up in detail here:
https://shubhra.dev/tutorials/performance-first-ui-mastery-guide-2026

That one goes deeper into how to actually implement this in real apps. This post is just the moment where the problem becomes obvious.

A quick way to test this

While working through this, I built a small quiz to check if I actually understood the idea or was just agreeing with it.

Here’s one of the questions:

A user clicks a button.
The server responds in 80ms.
They click four more times.

What actually failed?

Most people still go to backend performance first.

If that was your instinct too, you’ll probably find the rest useful:

https://shubhra.dev/quiz/performance-first-ui

It’s short. Focused on real interaction problems. No trick questions.

One practical takeaway

Next time you write a click handler, check the order:

Does something change on screen immediately?
Or does all the work happen before the user sees anything?

That one decision is often the difference between a UI that feels fast and one that feels broken.

If you’ve run into this in your own apps, I’m curious what caused it and how you approached it.

Why Most React Infinite Scroll Hooks Fail in Production (and the One That Fixed It for Me)

Shubhra Pokhariya — Thu, 30 Apr 2026 11:28:52 +0000

I used to believe infinite scroll was one of the simplest features to implement.

Fetch data → append to a list → load more on scroll.

Easy, right?

That’s exactly how most tutorials show it.

And honestly… it works.

Until it doesn’t.

The Bug That Changed Everything

One bug completely changed how I think about infinite scroll.

A user changed a filter → the list reset → new data loaded.

Everything looked correct.

Then a couple of seconds later…

the old results came back and overwrote the new ones.

No errors. No warnings.

Just silently broken UI.

What actually happened?

A slow request from the previous state finished late and updated the UI with stale data.

That was the moment I realized:

Infinite scroll doesn’t break in demos.It breaks with real users, real timing, and real networks.

Where Things Start Falling Apart

After that, I started noticing the same issues again and again:

Stale requests overwriting fresh data after reset
Retry logic fetching the wrong page
IntersectionObserver continuing to fire after errors
Duplicate requests in React Strict Mode
Loading states that never resolve

These problems rarely show up locally.

But in production, they show up fast.

What I Actually Needed

Not another demo.

Something I could trust in a real app.

So I built a hook around one idea:

Control the async flow. Don’t just “load more data”

What This Hook Handles

✔ Cancels stale requests (no overwrite bugs)
✔ Smart retry logic (correct page every time)
✔ Proper observer cleanup (no leaks)
✔ React 18+ Strict Mode safe
✔ Clear initial vs pagination loading states
✔ Manual loadMore, reset, and retry
✔ Zero dependencies

Basic Usage

const {
  items,
  isInitialLoading,
  hasMore,
  error,
  loadMoreRef,
  retry,
  reset
} = useInfiniteScroll({
  fetchFn: async (page, signal) => {
    const res = await fetch(`/api/posts?page=${page}`, { signal });
    return res.json();
  },
  pageSize: 20,
});
return (
  <div>
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>

    {/* Sentinel element */}
    <div ref={loadMoreRef} />

    {error && <button onClick={retry}>Retry</button>}
  </div>
);

Real Use Case: Reset on Filter Change

This is where most bugs happen.

useEffect(() => {
  reset(); // cancels old request + reloads safely
}, [filter]);

Without proper handling, this is exactly where stale data bugs appear.

Why AbortController Matters So Much

Before using it:

old requests still resolved
stale data overwrote the UI

After using it:

old requests get cancelled immediately
they never reach your state

That single change removes an entire class of bugs.

One Honest Note

This hook handles most real-world issues.

But for very large lists, you should still use virtualization
(like react-window or tanstack/virtual).

Infinite scroll solves loading.

Virtualization solves rendering.

Try It Yourself

You can grab the full hook here:

👉 https://shubhra.dev/snippets/use-infinite-scroll

MIT licensed
free to copy and modify
built for real production cases

Final Thought

I didn’t build this because infinite scroll is hard.

I built it because the small edge cases are what break real products.

Slow APIs. Fast users. Overlapping requests.

That’s where things actually fall apart.

Curious - what broke for you?

Have you ever hit a weird infinite scroll bug in production?

Something like:

duplicate data
stale UI
loading that never stops

Would genuinely love to hear what you ran into.

I Turned My Blog Into a Full Developer Platform (Tutorials + Snippets + Quizzes + Tools)

Shubhra Pokhariya — Tue, 28 Apr 2026 12:25:37 +0000

I’ve been working on building a developer platform with tutorials, reusable code snippets, interactive quizzes, and practical tools. This post shares what changed and what I’m building now.

For the past few months, I’ve been a little quiet here.

If you’ve been active on Dev.to regularly, you probably noticed I wasn’t reading as many posts, commenting, or sharing like I used to. And honestly, I missed that.

This community has always been one of my favorite places to learn and grow. Reading how others think, build, and solve problems has helped me a lot in my own journey.

So stepping away from that wasn’t easy.

Why I Went Quiet

I reached a point where I felt like just writing blog posts wasn’t enough for me anymore.

Don’t get me wrong, I still love writing. But I kept thinking:

What if I could make something more useful than just articles?

Something that helps people not only read, but also:

try things quickly
test their understanding
and actually use code in real projects

That idea stayed in my mind for a while.

And instead of talking about it, I decided to just build it.

What I’ve Been Working On

I took my simple blog and slowly turned it into something more complete.

Now it’s not just posts. It includes:

Tutorials that go step by step

Here’s how one of the tutorials looks:

Small, practical code snippets you can directly use

A quick example of a reusable snippet in action:

Quizzes to test concepts in a quick way

Here’s a quick look at how the quiz works:

Here’s a small taste of what the quizzes look like:

1. What does the === operator do?

Checks for value equality only
Checks for reference equality only
Checks for both value and type equality without coercion
Assigns a value

→ Correct answer: Checks for both value and type equality without coercion

2. What is a closure in JavaScript?

A way to immediately end a function
A function that retains access to its outer scope
A syntax error
A loop

→ Correct answer: A function that retains access to its outer scope

3. What will typeof null return?

'null'
'undefined'
'object'
'number'

→ Correct answer: 'object'

A couple of products built from things I personally needed

It’s still growing, still improving, and definitely not perfect.

But it feels closer to what I actually wanted to create.

What Changed for Me

Earlier, I was mostly focused on sharing information.

Now I’m trying to focus more on usefulness.

Instead of just explaining things, I want to:

make it easier to apply them
keep things simple and practical
and help someone save time when they’re stuck

Even the smallest snippet can be helpful if it solves a real problem.

I Missed This Community

One thing I realized during this time is how much I value this space.

Reading posts here, seeing different approaches, and learning from others is something I genuinely enjoy.

I missed that part.

So I’m coming back, not just to share, but also to read, learn, and engage again.

What You’ll See From Me Now

I’ll start sharing more regularly again, but with a slightly different approach.

You’ll see things like:

small useful snippets
short explanations
occasional deep tutorials
and some interesting questions or quizzes

Nothing too heavy. Just practical and helpful.

If You Want to Check What I Built

Here’s how everything comes together:

If you’re curious, you can take a look here:

https://shubhra.dev/

No pressure at all. Just sharing what I’ve been working on.

One Small Thought

Sometimes we feel like we need to keep posting consistently no matter what.

But taking a step back to build something meaningful can be just as important.

For me, this phase helped me rethink what I actually want to create and share.

And I’m glad I took that time.

I’m looking forward to reading your posts again and being more active here.

If you’ve been working on something quietly too, I’d love to hear about it.

Performance First UI Taught Me More Than Any Framework Ever Did

Shubhra Pokhariya — Mon, 12 Jan 2026 10:40:43 +0000

The slowest app I ever worked on had a perfect performance score.

That sentence used to confuse me.

Everything was optimized. Bundles were trimmed. Images were compressed. Lighthouse smiled back at me like a proud teacher.

And yet, users kept behaving strangely.

They clicked twice.

They hesitated.

They abandoned flows halfway through.

At first, I blamed users. Then devices. Then networks.

Eventually, I blamed myself.

That was the moment I started understanding performance first UI.

Speed is not what developers think it is

As developers, we grow up believing speed is a number.

Milliseconds.

Scores.

Graphs.

But users never see numbers. They feel moments.

The moment after a click.

The moment after a tap.

The moment when they expect acknowledgment.

If nothing happens in that moment, something breaks not technically, but emotionally.

The day I stopped trusting Lighthouse alone

Lighthouse is useful. It taught an entire generation to care about performance.

But in 2026, relying on Lighthouse alone is like judging a car by how fast it accelerates on an empty track.

Real users drive in traffic.

They scroll while data loads.

They click while JavaScript executes.

They type while hydration finishes.

That’s where performance first UI lives, not at load time, but during interaction.

Interaction is the real contract with the user

A page load is an introduction.

An interaction is a promise.

When a user clicks a button, they are not asking for data. They are asking for reassurance.

Did you hear me?

Are you working?

Can I trust you?

If your interface stays visually silent, the promise is broken.

Why Interaction to Next Paint quietly changed everything

Interaction to Next Paint does something rare in web metrics.

It measures reality.

Not when logic finishes.

Not when promises resolve.

But when pixels change.

This sounds obvious, but it reframes how you write UI code.

Because suddenly, doing work before paint feels dangerous.

If this shift in thinking around Interaction to Next Paint resonated with you, I’ve explored it in much more depth in my long-form guide Performance First UI Mastery: A Critical Guide for 2026 Developers, where I break down real-world examples, beginner-to-advanced concepts, and how this mindset plays out in modern Next.js apps.

The hidden enemy of modern interfaces

Most INP problems are not caused by slow servers.

They are caused by good intentions.

Too much logic inside event handlers
Too many state updates
Too many components reacting at once

Everything works. Everything is correct. Everything is just slightly late.

And that slight lateness compounds.

The small habit that fixed most of my issues

The biggest improvement I ever made to interaction performance was embarrassingly simple.

I stopped doing real work before showing feedback.

Instead of:

Click → compute → update UI

I switched to:

Click → update UI → compute

Nothing fancy. No new libraries.

Just respect for the paint cycle.

Why modern Next.js makes this mindset possible

Next.js quietly evolved alongside performance first UI thinking.

Partial Prerendering lets interfaces appear ready before they are complete.
Streaming lets content arrive without blocking interaction.
Server Actions let the UI move first and confirm later.
Edge Middleware removes entire decision trees from the client.

Used correctly, these tools keep the browser free to respond.

Performance is not about doing less, it’s about doing things later

This was a hard lesson for me.

I used to chase minimalism. Fewer features. Smaller bundles.

But performance first UI taught me something better.

You can do a lot, just not all at once.

Defer what the user cannot see.

Delay what the user does not care about yet.

Focus on what the user just did.

The business side developers rarely talk about

Here’s an uncomfortable truth.

A sluggish interaction costs more than a slow page load.

Because interaction delay happens when the user is already invested.

They clicked.

They intended.

They were ready.

Losing them here hurts conversion far more than a slow landing page.

Performance is becoming a human skill again

In 2026, AI can generate components.

AI can refactor code.

AI can optimize assets.

But AI cannot feel hesitation.

It cannot sense when a transition feels awkward.

It cannot sense when feedback arrives too late.

That sensitivity is now the developer’s real value.

What performance first UI actually demands from us

It demands patience.

It demands that we observe our own interfaces instead of trusting dashboards.

It demands that we click our own buttons slowly and ask:

Does this feel respectful?

Not impressive.

Not clever.

Respectful.

Final thought

Performance first UI is not a trend. It is a correction.

A return to building software that listens.

If your UI responds instantly, users forgive imperfections.

If it hesitates, they remember.

In the end, performance is not about speed.

It is about trust.

How CSS Animation Helped Me Build Interfaces That Feel Alive

Shubhra Pokhariya — Mon, 22 Dec 2025 06:24:42 +0000

I always believed great UI was about color, spacing, structure, and typography. I spent years improving those things. I obsessed over grids. I experimented with type scales. I rewrote layout systems again and again.

Yet something still felt missing.

Every interface I created worked perfectly, but emotionally it felt silent. It behaved like a machine. Nothing moved unless a page refreshed. Nothing acknowledged the user. I did not realize how empty that silence was until I compared my projects with modern interfaces around the web.

Some apps felt warm and alive, even though their layouts were simple. Their buttons breathed. Their cards shifted gently when hovered. Even status messages faded in and out like they had personality.

I kept asking myself

How are they doing that?

That question pushed me toward CSS Animation.

Not as a design trend
but as a missing piece of expression.

My First Real Encounter With Motion

My turning point arrived inside a dashboard project. Everything looked clean and minimal. The data tables worked. The navigation was solid. The code was tidy.

But the experience lacked a pulse.

One evening while polishing the UI, I decided to animate only a single button. Not to impress anyone, but to understand how it would feel. I added a soft hover lift and a clearer color transition. Nothing dramatic.

The moment I refreshed the browser
the UI reacted like it suddenly woke up.

The button rose slightly.

The shadow deepened.

It felt like the interface acknowledged me.

It was such a small change that the code barely filled a few lines, and yet the product felt more professional instantly.

That tiny success completely changed how I saw CSS Animation.

Why Motion Matters To Users

Modern users expect movement even if they cannot explain why.

Motion tells the brain something is happening.

It guides attention with subtle cues.

It communicates structure faster than text.

When a button lifts
you know it is clickable.

When content fades gently
you understand that something changed without reading anything.

Motion replaces confusion with instinct.

Once I understood that, I saw animation everywhere:

apps, websites, mobile UI, operating systems, ecommerce stores.

Motion has become the language of modern interaction.

CSS Animation Is Not Just Decoration

Before learning it deeply, I believed animation was fancy.

I assumed it slowed pages down.

I thought it was extra work for no real benefit.

All of that was wrong.

CSS Animation can improve usability in extremely practical ways:

Guiding users to the next step
Confirming they clicked something
Building visual rhythm
Reducing visual shock
Improving brand identity
Creating focus without clutter

Motion is not frosting on top of UI. It is part of UI itself.

The Mindset Shift That Helped Me Learn Faster

The biggest challenge was learning how to think about motion.

I stopped asking How do I make this look cool?

and started asking What should the user feel here?

When they open a page, maybe they should feel welcomed.

When they press save, maybe they should feel confirmed.

When they hover over content, maybe they should feel engaged.

That mindset turned animation into storytelling.

Why CSS Animation Works So Well With Modern UI

CSS Animation is not heavy, nor complicated, nor dependent on JavaScript.

It is built to run smoothly if you animate the right properties.

Transforms and opacity create GPU-powered motion that feels fluid even on average devices.

The more I practiced, the more confident I became because I saw that animation can stay clean and fast when done with purpose.

The Most Surprising Part

Clients noticed the improvements immediately.

They could not describe what changed in technical language,

but they kept saying the same thing -
"This feels better.",

Not This looks better, but This feels better.
That sentence taught me something powerful:

Users care about feeling, not code.

A New Way Of Seeing My Projects

Today I build interfaces very differently.

I do not start by applying motion everywhere.

I begin by searching for moments where the UI speaks to users.
Moments that deserve attention, and moments that need softness.

Sometimes it is a card hover.

Sometimes it is a hero title reveal.

Sometimes it is a form success message.

Motion is now part of my design decisions, not an afterthought.

Want To Learn How I Apply CSS Animation To Real UI

I recently wrote a deep story and breakdown on my blog showing how CSS Animation reshaped my understanding of UI feeling and movement.

You can read it here:

👉 https://blog.shubhra.dev/css-animation-level-up-ui

If you are a developer who wants your UI to feel more human, this will help you see animation differently.

Final Thought

The moment you experience your first animated interaction that feels natural, not flashy, you understand why motion matters.

CSS Animation is not only a visual tool, it is emotional design.

And once you learn it, you never see UI the same way again.

The CSS Positioning Chaos: Why Your Elements Run Away (And How I Finally Mastered the 5 Keys)

Shubhra Pokhariya — Fri, 28 Nov 2025 07:54:55 +0000

There is a special kind of chaos that only frontend developers understand.

The kind where your layout looks perfect one second and then suddenly one button escapes to the top corner of the screen like it has its own dreams and ambitions.

That chaos usually has a name: CSS Positioning.

Every developer goes through this phase.

Every beginner gets confused.

And honestly, even after years of working with CSS, I still smile whenever someone asks me:

“Why does my element move when I scroll?”

Because that question reminds me of my own journey, a journey full of tiny mistakes, confused evenings, and small victories that made CSS feel less like a puzzle and more like a friend.

Recently, I wrote a full blog post on my main site where I broke down CSS Positioning in the simplest, most practical way I could.

Today I wanted to share a little behind the scenes of that post and also explain why CSS Positioning deserves more love than it gets.

The Phase Where CSS Positioning Made Me Doubt My Career Choices

Let me tell you something honestly.

In my early days of coding, nothing confused me more than absolute and relative.

I remember placing a badge inside a hero section and the moment I refreshed the page, it flew somewhere completely unrelated.

I thought I broke the browser. I even restarted my laptop once thinking something was wrong with VS Code.

Little did I know it was just CSS Positioning doing its usual drama.

static was too simple
relative felt too subtle
absolute felt too free
fixed felt too stubborn
sticky felt like magic

And because I did not understand their personalities, I kept fighting them instead of letting them help me.

It took me weeks to finally understand that CSS Positioning is not just about moving elements around.

It is about understanding how the browser thinks.

How it calculates boundaries.

How it decides the containing block.

How each element follows a very logical set of rules.

Once I understood this, the fear disappeared.

And CSS started feeling like a superpower.

The Beauty Behind Understanding CSS Positioning

When you truly understand CSS Positioning, you begin to see your layout differently.

Static becomes your calm baseline.
Relative becomes your gentle adjustment tool.
Absolute becomes the creative freedom you use when you want elements to float exactly where you want.
Fixed becomes your loyal companion for floating buttons and sticky helpers.
Sticky becomes the modern magic that makes long pages feel smoother.

The moment you master these five:

your designs stop breaking
your elements stop running away
and your confidence grows instantly

This is why CSS Positioning is not just a “topic” — it is a core foundation that every modern frontend layout quietly depends on.

The Best Way To Learn CSS Positioning Is Not Memorizing It

One of the main things I shared in my WordPress post is something simple but important:

CSS Positioning is not learned through memorization.

It is learned through experience.

You learn it by:

building small boxes
adding a badge
scrolling a page
trying absolute without relative
trying sticky inside a tiny container
placing a button with fixed
and observing every single behavior

This hands‑on curiosity is what transforms CSS Positioning from confusing to intuitive.

And once it clicks, you will wonder how you ever struggled with it.

Why This Topic Deserves More Attention

We often jump directly into Flexbox, Grid, animations, Tailwind, frameworks, and component libraries.

But behind all of them, positioning still plays a silent role.

The moment something goes wrong,

the moment a layout shifts,

the moment an element overlaps,

the moment a menu disappears,

we all return to the same root question:

“Where is this element positioned, and relative to what?”

Understanding CSS Positioning early saves so much frustration later.

Final Thoughts

CSS Positioning is not scary.

It is simply misunderstood.

And once you understand how these five values behave, you will start designing with more confidence, clarity, and creativity.

Whether you are:

a beginner trying to place a small badge
a student building a landing page
or someone revisiting fundamentals after years

CSS Positioning is one of those topics that rewards you every time you give it attention.

If you want the full detailed breakdown, the real examples, and the step‑by‑step mental model, check out my complete WordPress guide:

👉 CSS Positioning: The 5 Keys to Master Static, Relative, Absolute, Fixed, Sticky

How CSS Grid Changed the Way I Build Web Layouts

Shubhra Pokhariya — Fri, 21 Nov 2025 08:36:47 +0000

I remember the first time I tried building a multi-section landing page. Everything seemed fine until I had to align cards, features, and hero sections across different screen sizes. Flexbox was great, it helped me align items neatly along a row or a column. Buttons were easy to center, cards aligned without stress, and navigation bars looked clean. But when it came to arranging rows and columns simultaneously, I felt like I was juggling invisible boxes.

At that point, I realized that while Flexbox is incredibly useful, it wasn’t enough for some layouts I wanted to build. That’s when I discovered CSS Grid, and it felt like a whole new world opened up. Suddenly, I could control both rows and columns, manage spacing effortlessly, and create layouts that scaled beautifully on different devices. Unlike Flexbox, which works one direction at a time, Grid lets you think of your layout in two dimensions, like designing a chessboard where each piece has its own space, but the whole board adapts as needed.

Why CSS Grid Matters

CSS Grid isn’t just a new layout tool. it’s a paradigm shift in how we approach web design. Here are a few reasons why I love using it:

Two-Dimensional Control – With Grid, you can define both rows and columns simultaneously. This makes complex layouts much simpler than using multiple Flexbox wrappers.
Simpler Responsiveness – Media queries, auto-fit, and minmax make responsive design feel natural. You define the structure once, and it adapts gracefully across devices.
Cleaner Code – Less nested markup, fewer hacky margins, and more maintainable CSS. Your code feels organized, and it’s easier for others (or future you) to understand.
Flexible Combinations – Grid and Flexbox aren’t competitors. I often use Grid to structure sections and Flexbox inside grid items for precise alignment.

Think of Flexbox as a Swiss Army knife, perfect for one-dimensional tasks. CSS Grid is more like a blueprint: it plans the structure of your entire layout. And when you combine them, building even complex sections becomes surprisingly intuitive.

Breaking Down the Basics

Before diving into full layouts, it’s helpful to understand the building blocks:

Grid Container – Turn any parent container into a grid by setting display: grid. Everything inside becomes a grid item automatically.
Grid Items – Direct children of the container that you can place and size using Grid properties.
Grid Template Columns – Define how many columns your grid will have and their proportions. For example:

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

Gap – Replace manual margins with gap for both rows and columns.

.container {
  gap: 20px;
}

Fraction Units (fr) – Divide space proportionally. For example, 1fr 2fr gives the first column 1 part and the second column 2 parts.

Auto-Fit & Auto-Fill – Make responsive columns that adjust automatically depending on available space.

Once you understand these fundamentals, you can start building layouts that scale across devices without headaches.

My First Real Project

When I tried my first product grid, I was amazed at how effortless it felt. Previously, I’d spend hours tweaking margins and floats to make cards line up evenly. With CSS Grid:

.products {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  gap: 30px;
}

Even with varying content lengths, everything stayed aligned beautifully. Adding hover effects, card spacing, and images became smooth and predictable. I realized I could build dashboards, landing pages, and product sections without overcomplicating the markup.

Making it Fully Responsive

Responsive design used to be the part I dreaded. CSS Grid made it easy:

@media (max-width: 1024px) {
  .grid {
    grid-template-columns: repeat(2, 1fr);
  }
}

@media (max-width: 600px) {
  .grid {
    grid-template-columns: 1fr;
  }
}

With a few media queries, the layout automatically collapses to fit tablets and mobile screens. No extra wrappers, no messy margin hacks, no complicated nesting. Just clean, intuitive, and flexible layouts.

Beyond the Basics

Once I mastered the fundamentals, I started experimenting:

Nested Grids – Perfect for dashboards or multi-section layouts.
Hero Sections – Divide the screen visually between text and imagery, all fully responsive.
Aligning Items – Centering, stretching, and fine-tuning placement is straightforward with justify-items and align-items.
One of my favorite things is combining Grid and Flexbox. For example, using Flexbox inside a Grid card keeps buttons, icons, and text perfectly aligned without extra CSS gymnastics.

Lessons I Learned While Mastering CSS Grid

When I first started experimenting with CSS Grid, I made some mistakes that slowed me down. These are things I wish I knew from the start:

Not declaring the grid container properly – Sometimes I’d forget display: grid, and nothing seemed to work.
Rigid column widths – Using fixed pixels made layouts brittle, especially on mobile screens. Switching to flexible fractions (fr) solved this instantly.
Too many nested grids too soon – I tried to nest grids for every tiny section, which made the code messy and hard to debug.
Skipping mobile testing – A layout may look perfect on desktop but break completely on smaller screens if you don’t check.
Not thinking about combining Flexbox – Some elements inside a grid need precise alignment. Using Flexbox inside a grid item is a game-changer.

Learning from these mistakes helped me write cleaner, more maintainable code and made creating responsive layouts much faster.

Flexbox and CSS Grid: How I Use Them Together

I often get asked: Should I stick to Flexbox or switch entirely to Grid?

Here’s how I see it now:

Flexbox is perfect when you’re dealing with a single row or column. Think navbars, simple card layouts, or aligning buttons, anywhere you need to align elements along one direction.
CSS Grid shines when you need two-dimensional control,rows and columns simultaneously. Dashboards, product sections, or multi-part landing pages are great examples.

The trick is not to see them as competitors. I often structure the page using Grid for the main layout and then use Flexbox inside specific grid items to align content perfectly. This combination saves time and keeps layouts consistent across devices.

Where to Go From Here

If you want a practical, step-by-step guide with real-life examples, screenshots, and fully explained techniques, I’ve written a complete blog post that goes deep into CSS Grid. It covers everything from simple product grids to advanced layouts, nested grids, auto-fit/minmax, and more.

You can check out the full guide here: CSS Grid Responsive Layouts Made Easy: A Complete Guide

Takeaways

CSS Grid transforms the way you build web layouts, making complex designs intuitive and manageable.
Combine Grid and Flexbox to get the best of both worlds.
Start small, experiment with product sections or hero layouts, then gradually explore nested grids and advanced properties.

If you’ve ever struggled with alignment, responsiveness, or messy layouts, CSS Grid can be a game-changer. And with a little practice, it’ll feel natural, clean, and even enjoyable to work with.

Understanding Flexbox: A Beginner’s Journey to Perfect CSS Alignment

Shubhra Pokhariya — Mon, 10 Nov 2025 10:53:28 +0000

I still remember the day I met Flexbox.

Not the “oh wow this is cool” kind of meeting, but the “why is nothing aligning right?!” kind.
My divs were misbehaving, my buttons refused to center, and I had started questioning every life choice that led me to CSS.

That was the moment I realized:

understanding Flexbox isn’t about memorizing properties, it’s about changing how you think about layout.

The Moment Everything Clicked

I used to picture HTML elements like rigid boxes, stacked on top of each other, bumping into margins, floating aimlessly.

Then one day, while debugging yet another layout mess, someone said:

“Stop fighting the boxes. Let them flex.”

It sounded poetic… and confusing.

But when I applied display: flex; for the first time, it was like the page suddenly listened.

My boxes started behaving like a team, aligning, wrapping, adjusting naturally without me wrestling with float or endless position: absolute;.

That’s when Flexbox stopped feeling like a feature… and started feeling like a mindset.

What Flexbox Really Does

Here’s the simplest way I can describe it:

Flexbox lets your elements negotiate space inside a container.

They decide based on your rules who gets to stretch, who stays compact, and how they all align together.

When you declare:

display: flex;

you’re basically saying:

“Hey container, you’re in charge now. Make your children behave intelligently.”

From there, a few key properties become your toolkit:

1) justify-content

It’s all about horizontal alignment.

Want everything centered across the main axis?

   justify-content: center;

Boom, your elements snap right into place.

2) align-items

Now we’re talking vertical balance.

Need everything to line up perfectly in the middle?

   align-items: center;

It’s like gravity for your UI.

3) flex-direction

By default, items align in a row (left to right).

Change it to a column, and suddenly your layout flows top-to-bottom.

   flex-direction: column;

It’s like rotating your design without touching HTML.

4) flex-wrap

Ever had a row that overflowed like an overstuffed suitcase?

With this, elements gracefully wrap to the next line instead of breaking everything.

   flex-wrap: wrap;

5) align-content

When you have multiple rows, this property decides how the rows themselves align inside the container.

It’s subtle but powerful when you’re designing grids or dashboards.

Why Developers Fall in Love with Flexbox

Because it feels logical.

You stop micromanaging every pixel and start describing relationships.

It’s not about positioning boxes anymore, it’s about teaching your layout how to behave.

Once I understood that, my workflow changed:

No more nested div chaos
No more guessing why a button won’t center
And best of all, my designs finally stayed responsive without writing 50 media queries

When to Use It

Flexbox shines for one-dimensional layouts, anything in a row or column.

If you’re building:

navbars
cards in a single line
buttons spaced evenly
or vertically centered login forms

Flexbox is your best friend.

For full grid layouts (like dashboards or galleries), CSS Grid is the next step.

But for most UI tasks, Flexbox is faster, simpler, and more intuitive.

The “Aha!” Lesson

The moment you stop thinking in pixels and start thinking in relationships, CSS becomes fun again.

You realize Flexbox isn’t about commands, it’s about conversation between elements.

And once you feel that click, you’ll never go back.

Read My Full Flexbox Deep-Dive

This was a gentle walk through the why behind Flexbox.

If you’d like a more practical, step-by-step guide with examples and clear visual breakdowns, you can read my full post here:

👉 How to Fix Common CSS Alignment Issues : A Simple Flexbox Guide for Beginners

That one dives into real-world alignment bugs, explains each fix visually, and includes a quick property reference for beginners.

Final Thought

CSS can feel confusing at first, but once you understand the patterns behind it, everything starts to flow.

Flexbox is one of those patterns that makes you fall back in love with frontend again.

So next time you’re stuck trying to center a div, take a deep breath, set display: flex;, and let your layout breathe.

Breaking Code, Building Skills: Lessons from My Early JavaScript Errors

Shubhra Pokhariya — Sun, 02 Nov 2025 10:57:59 +0000

Every coder has that one day when nothing works and the console turns bright red.

That was me too. I remember sitting in front of my laptop, watching endless error messages appear, wondering if maybe coding just wasn’t for me. But slowly, one bug at a time, I began to understand that those “failures” were actually little teachers hiding behind red text.

Each error shaped how I think, how I stay calm, and how I solve problems. Today, I want to share the first five coding errors that helped me grow into a more confident developer and taught me valuable lessons about patience, logic, and persistence.

1. How a Simple Syntax Error Turned Into My Favorite Lesson

My first coding error was the simplest one, and yet it felt like a disaster.

I had written my first JavaScript function and proudly hit “Run,” only to be greeted with:

Uncaught SyntaxError: Unexpected token

I stared at my code for ages, convinced something mysterious was wrong, only to realize I had forgotten a closing parenthesis. That tiny bracket had caused the chaos.

function greet(name {
  console.log("Hello, " + name);
}

The fix was almost funny when I saw it:

function greet(name) {
  console.log("Hello, " + name);
}

That was my first lesson in humility. Coding errors are not enemies; they’re mirrors showing exactly where you stopped paying attention. Every syntax mistake reminds me to slow down, breathe, and read what the computer is actually telling me.

2. The Mystery of Undefined That Every Coder Faces

Feeling more confident, I started building a tiny to-do app in JavaScript. Everything seemed fine until one line broke my confidence completely:

TypeError: addTask is not a function

After an hour of confusion, I found the culprit. I had written addtask in one place and addTask in another. That one lowercase letter changed everything. JavaScript didn’t care about my intention; it followed the exact name.

function addtask(task) {
  tasks.push(task);
}
addTask("Learn JavaScript");

The corrected version worked instantly:

function addTask(task) {
  tasks.push(task);
}
addTask("Learn JavaScript");

That day, I learned that naming consistency is not just good practice, it’s a form of respect for your future self and for anyone reading your code. Many beginners think they have logic issues when in fact, they just have naming errors. Consistency clears more bugs than you’d expect.

3. The React Moment That Finally Made “Undefined” Click

When I started learning React, I moved from simple syntax errors to more mysterious ones.

I remember building a UserCard component that was supposed to display a name:

function UserCard({ user }) {
  return <p>{user.name}</p>;
}

<UserCard />

My console flashed with:

TypeError: Cannot read properties of undefined (reading 'name')

At first, I thought React had a bug. But no, the problem was mine. I hadn’t passed the user prop at all.

<UserCard user={{ name: "Shubhra" }} />

That fix worked immediately.

It also taught me one of the most important lessons about JavaScript coding errors, never assume data exists until you’ve confirmed it.

Now, I always handle this safely:

function UserCard({ user }) {
  return <p>{user?.name || "Anonymous User"}</p>;
}

That little question mark (?.) has saved me from countless crashes since.

4. The Next.js Fetch Coding Error That Tested My Patience

My next big challenge came in a Next.js project where I needed to fetch data from an API. The setup looked perfect, but the console threw a scary red message:

Error: fetch failed

I checked my connection, rechecked my endpoint, and even switched networks. Nothing worked. Finally, after far too long, I saw the real issue, I had typed htp:// instead of https://.

await fetch("htp://api.example.com/data");

It looked right at a glance, but one missing “s” broke everything.

Once corrected, it ran beautifully:

const res = await fetch("https://api.example.com/data");

That bug taught me patience and the power of slowing down.

When you face coding errors like this, it’s not always about fixing, sometimes it’s about observing. Debugging isn’t rushing to solve; it’s tracing your logic calmly, one small step at a time.

5. When a Logic Mistake Made Everything Click

My final lesson came from a bug that didn’t crash my code, it just gave me the wrong answer.

I wrote a small loop to total expenses:

const prices = [100, 200, 300];
let total = 0;

for (let i = 0; i <= prices.length; i++) {
  total += prices[i];
}

The result was NaN, and I couldn’t figure out why.

Then I noticed the condition: I had used <= instead of <. That tiny sign caused the loop to access prices[3], which didn’t exist.

Corrected version:

for (let i = 0; i < prices.length; i++) {
  total += prices[i];
}

That one small fix changed everything. Logic errors like this are the best teachers. They don’t shout in red text, they whisper. They make you think more deeply and check your assumptions.

What These Coding Errors Taught Me

Looking back, each of these moments shaped me as a developer.

Syntax errors taught me precision.
Undefined function errors taught me discipline.
React property errors taught me data awareness.
Fetch errors taught me patience.
Logic errors taught me analytical thinking.

Together, they gave me a mindset: that debugging isn’t punishment, it’s exploration.

Each fix gave me confidence, and each small victory reminded me why I love building things from scratch.

Debugging and Growth Go Hand in Hand

When I began, I thought great developers wrote perfect code. Now I know they write buggy code, but they fix it thoughtfully. Debugging is where confidence, creativity, and calm meet.

Those first five coding errors built the foundation of my developer journey. They taught me to think clearly, to listen to my console without fear, and to enjoy the learning process.

If you are facing your own set of errors, don’t fight them.

Ask your code what it’s trying to teach you.

That’s how confusion turns into confidence and every mistake becomes a milestone.
👉 Read the full story here: My First 5 Coding Errors

🌿 How My Winter Garden Inspires Better UI Design

Shubhra Pokhariya — Sun, 12 Oct 2025 06:38:01 +0000

Hey developers 👋

This Sunday, I swapped my code editor for a pair of gardening gloves! Lately, I’ve been sowing winter flower seeds, visiting nurseries for bright seasonal plants, and turning my porch and terrace into a little world of color. With green mountains and trees surrounding my home, the view feels like a living color palette — soft, balanced, and full of inspiration. 🌸

Gardening has a funny way of reminding me of UI design. Arranging plants makes me think about layout, contrast, and visual balance, almost like styling components in React or picking the perfect color combinations in CSS. 🌼

Every pot, every bloom, and every light I hang for Diwali brings the same satisfaction as refining a clean, responsive design. It’s creative problem solving, just in a different medium.

I’ve realized that stepping away from the laptop isn’t a break from creativity; it’s part of it. Watching something grow slowly reminds me that building products and developing skills takes the same care and patience.

Do you have a creative ritual outside of coding that fuels your ideas? Maybe it’s art, cooking, music, or gardening like me. I’d love to hear what helps you stay inspired beyond the screen. 🌱

Here’s to nurturing our code, our creativity, and our calm, one plant and one project at a time. 💻🌿

Why Small Coding Habits Matter for Developers

Shubhra Pokhariya — Mon, 06 Oct 2025 06:47:24 +0000

Ever looked at your old code and wondered what you were thinking? That confusion, frustration, or second-guessing your own logic is something every developer experiences. The good news is, adopting a few simple coding habits can prevent these moments and completely transform how you write and maintain code.

Over the years as a web developer, it has become absolutely clear that great code is not just about solving problems or getting features done. It’s about the habits we develop that shape how sustainable, maintainable, and scalable our code becomes.

In my recent projects, focusing on small but consistent habits has truly transformed my workflow. These habits are not tied to specific languages or frameworks and are foundational practices applicable across the board. If you're aiming to write code that lasts and brings you less frustration down the line, these three habits are essential to master.

For a more detailed guide with deeper insights and examples, check out my full article here: How 3 Small Coding Habits Can Transform Your Workflow and Code Quality

1. Writing Comments That Explain the "Why," Not Just the "What"

Comments often get a bad rap because they are either ignored or misused. But when used wisely, comments become a powerful narrative tool for your code. It’s easy to describe what the code does, but the real value comes from explaining why a solution was chosen.

For example, consider this snippet from a recent project:

// Using debounce to limit API calls during rapid input changes
const debouncedSearch = debounce(handleSearch, 300);

This comment clearly states why debounce is used, preventing future confusion if someone wonders why the API isn’t called instantly.

When you come back to your code weeks or months later, or share it with a teammate, these explanatory comments save precious time and reduce guesswork. They also help during debugging, as understanding the intention behind code makes tracking bugs faster.

2. Refactor Regularly to Avoid Technical Debt

Refactoring is not just a phase reserved for major releases. I learned this the hard way when I ignored small code cleanups, and my project quickly became difficult to manage.

Instead, integrate refactoring as a natural part of your development cycle. After adding a new feature, or while fixing bugs, take a few minutes to tidy up variable names, simplify complex logic, or break down large functions into smaller, reusable ones.

Here’s a quick before-and-after example of refactoring a function for clarity:

Before:

function processData(data) {
  // lots of nested if statements and unclear variable names
  if (data && data.items) {
    for (let i = 0; i < data.items.length; i++) {
      if (data.items[i].active) {
        // process active items
      }
    }
  }
}

After:

function isActive(item) {
  return item.active === true;
}

function processData(data) {
  if (!data?.items) return;

  const activeItems = data.items.filter(isActive);
  activeItems.forEach(item => {
    // process active items
  });
}

This cleaned-up version makes intent clearer, simplifies logic, and is easier to extend or debug.

3. Consistent Naming - The Unsung Hero

Good names act as hints to the purpose of variables, functions, and classes. I have found that adopting a consistent naming convention, whether camelCase, snake_case, or PascalCase, and sticking to meaningful, descriptive names drastically improves readability.

For example, naming a variable userAge is better than a vague ua, and a function called calculateInvoiceTotal communicates its purpose clearly. When everyone on the team follows the same naming standards, onboarding becomes simpler and collaboration more effective.

Why These Habits Matter Beyond Just Writing Code

Besides making your code cleaner, these habits reduce debugging time and ease peer collaboration. More importantly, they prepare your codebase for growth, making it easier to adapt to new features or requirements without scrambling in chaos.

Software development is a marathon, not a sprint. Writing code that you (or your team) can confidently revisit in six months without headaches is a professional skill worth investing in.

My Personal Takeaway

In my own journey, embracing these habits has changed how I approach challenges. I spend a little more time upfront, but the payoff is smoother development cycles and less last-minute troubleshooting.

When you feel overwhelmed by complexity, try breaking your workflow down to these essentials: meaningful comments, frequent refactoring, and disciplined naming. They form the backbone of sustainable software craftsmanship.

What Coding Habit Changed How You Work?

Building good habits is a continuous journey.I would love to hear about the coding practice that made the biggest difference in your projects, so please drop your tips in the comments or share your experiences.

How Perceived Performance Can Transform Your Next.js Projects

Shubhra Pokhariya — Fri, 26 Sep 2025 10:42:53 +0000

Performance isn’t just about load times, it’s about how fast your site feels to users. In this post, I’ll share practical strategies for improving perceived performance in Next.js projects with Tailwind CSS. From critical content rendering to smooth transitions, learn how to create faster, more engaging user experiences.

Why Perceived Performance Matters More Than Raw Metrics

Imagine you visit a website that loads its HTML, CSS, and JavaScript lightning fast according to Lighthouse reports, but the page remains blank or shows a spinner for several seconds. Despite the impressive metrics, the experience feels slow and frustrating.

On the other hand, a site that quickly displays meaningful content, even if it takes slightly longer to fully load everything feels fast and responsive.

This is the core of perceived performance: users judge a site by how quickly they see content they care about, not just when all resources finish loading.

Practical Strategies for Improving Perceived Performance in Next.js

Here are some tactics I’ve incorporated that helped my landing pages feel glitch-free and performant:

1. Prioritize Critical Content Rendering

Ensure that above-the-fold content renders immediately. This involves server-side rendering (SSR) crucial content with Next.js and deferring non-essential components.

Using meaningful loading skeletons or placeholders can also give users a smooth visual transition while other content loads.

2. Wise Use of Lazy Loading

Lazy loading images, videos, and scripts not visible on initial screen reduces the amount of work the browser must do upfront. Next.js's native image optimization combined with Intersection Observer APIs makes this manageable.

3. Minimize and Split CSS & JS Bundles

Tailwind CSS’s utility-first approach, combined with its built-in purge process (powered by JIT), effectively removes unused CSS classes during production builds, ensuring your CSS remains as small as possible.

For JavaScript, Next.js leverages modern features like tree shaking and automatic code splitting so users only download the necessary code per page, improving load times and performance.

To keep your bundles lean, regularly analyze them with tools like Webpack Bundle Analyzer, which fully supports Next.js 15 and integrates smoothly with Tailwind CSS projects. This helps you identify large modules or unused code you can optimize or remove.

4. Smooth UI Transitions

Seamless page transitions and animations mask load times and keep interfaces feeling fluid. Framer Motion and CSS transitions are great tools for this.

How These Improvements Impact User Experience

Focusing on perceived performance boosts:

User retention: Visitors are less likely to abandon slow-loading pages.
Conversion rates: Quicker content reduces friction in user actions.
SEO: Search engines value UX signals, which translate to better rankings.
Accessibility: Fast, clear loading benefits all users, including those on limited bandwidth.

See It In Action: My Landing Pages Built With These Principles

To put these ideas into practice, I built two landing page templates using Next.js and Tailwind CSS:

Launchpad: A lightweight, mobile-first landing page optimized for SEO and fast loading.
Launchpad Grow: A more advanced template including multi-language support, advanced analytics integration, and legal page scaffolding.

Both exemplify perceived performance principles and focus heavily on delivering smooth, fast user experiences.

Check them out and feel free to share thoughts or suggestions:

👉 Launchpad

👉 Launchpad Grow

Key Takeaways

If you’re short on time, here’s a quick summary of what focusing on perceived performance in Next.js can do for your projects:

Faster perceived speed: Users see useful content earlier.
Better Core Web Vitals: Optimized rendering and interactivity improve Google’s UX ranking signals.
Improved engagement: Smooth transitions and skeleton states reduce drop-offs.
Lightweight bundles: Tailwind CSS + Next.js code splitting keeps performance sharp.
Business impact: Happier users stay longer, convert more, and return.

By combining technical optimizations with user-centric design, you not only make your projects faster but also more resilient and future-proof.

What’s Your Go-To Performance Trick?

Performance optimization is an ongoing journey. I’d love to hear what tricks, tools, or methods you rely on to improve perceived performance or user experience in your projects. Let’s share knowledge and keep making the web better.

Final Thoughts

Building fast websites today is about more than improving numbers, it's about connecting with users through smooth, meaningful experiences. By prioritizing what users actually see and interact with, you create sites that feel faster and more enjoyable.

Whether you’re working with Next.js, React, or other frameworks, focusing on perceived performance will elevate your projects to a new level of quality.