DEV Community: Chhavi Kohli

Nullish Coalescing (??) - Handle Defaults the Right Way

Chhavi Kohli — Sat, 31 Jan 2026 17:55:20 +0000

Before ES2020, we(developers) mostly relied on the logical OR (||) operator for default values.

Let's say we want to set pageFromApi

const currentPage = pageFromApi || 1;

Issue

The || operator treats all falsy values as invalid:

0
'' (empty string)
false
null
undefined

EXAMPLE

// User is on page 0 (first page)
const pageFromApi = 0;

WRONG: page 0 gets replaced
const page = pageFromApi || 1;

console.log(page); // Output:1

Page 0 is valid, but || thinks it's falsy.

Nullish Coalescing (??)

The Nullish Coalescing Operator was introduced in ES2020 to solve this exact problem.

SYNTAX

const result = value ?? defaultValue;

EXAMPLE

// User is on page 0 (first page)
const pageFromApi = 0;

// CORRECT
const page = pageFromApi ?? 1;

console.log(page); // 0

Other Use Cases-

It also helps in code optimization.

// OR Logic
function getUsername(user) {
  if (user.name === null || user.name === undefined) {
    return "Guest";
  } else {
    return user.name;
  }
}

// OUTPUT examples:
getUsername({ name: "Chhavi" });   // "Chhavi"
getUsername({ name: "" });         // ""
getUsername({ name: null });       // "Guest"
getUsername({});                   // "Guest"

// Nullish Coalescing
function getUsername(user) {
  return user.name ?? "Guest";
}

// OUTPUT examples:
getUsername({ name: "Chhavi" });   // "Chhavi"
getUsername({ name: "" });         // ""
getUsername({ name: null });       // "Guest"
getUsername({});                   // "Guest"

Conclusion: same output but fewer lines of code.

When Should You Use ???

Nullish Coalescing(??):

0, false, or '' are valid values.
Handling API responses or optional configs.

Logical OR:

-Any falsy value should trigger a default.
-You intentionally want aggressive fallback behavior.

----------------------------************-----------------------------

Hoisting

Chhavi Kohli — Fri, 30 Jan 2026 10:06:27 +0000

“Why does my code sometimes work even when I use variables before declaring them?”

What Is Hoisting?

Hoisting in JavaScript is a behavior where declarations of variables, functions, and classes are processed and allocated memory during a compilation phase (Creation Phase) before the code is executed line by line.

This process is not a literal "moving up" of your code, but rather the JavaScript engine's way of creating an "environment record" for the current scope.

console.log(a);
var a = 10;

Output

According to definition from google variable is shifted to top. So output should be 10;

10❌
undefined✅

How?

Only declarations not initialisation

Under the Hood: The Two Phases

Creation Phase (Compilation/Memory Allocation):

The engine reads the entire scope of the code (global or function scope).
It identifies all function and variable declarations (var, let, const, function).
It allocates memory for these declarations in a memory container called the Variable Object.
For var declarations, a placeholder value of undefined is assigned.
For let and const declarations, they are hoisted but remain uninitialized (will discuss further in blog).
For function declarations, the entire function definition is stored in memory, allowing them to be called anywhere within their scope.

TEMPORAL DEAD ZONE - Zone created for the duration between memory allocated and initialisation statement is executed.

Execution Phase:
The engine begins running the code line by line.

Because memory has already been allocated, variables and functions are available for use, even if the line where they were "declared" in the source code hasn't been reached yet.
When the engine encounters an assignment (=), it updates the value in the allocated memory space.

How let, const hoisting different from var.

Intersection observer

Chhavi Kohli — Sun, 25 Jan 2026 10:49:39 +0000

what?

The Intersection Observer API is a modern JavaScript web API.

Observer lets you react when an element enters or leaves the viewport—efficiently and without performance pain.

Problem it solves.
Before Intersection Observer, detecting visibility usually meant:

Listening to scroll events
Manually calculating element positions
Running that logic constantly while scrolling

That approach:

Hurts performance
Scales poorly as pages get complex

why?

Much better performance Browser handles visibility checks internally No continuous scroll listeners Callbacks run only when visibility changes Result: smoother scrolling and lower CPU usage
Cleaner, simpler code Instead of math-heavy scroll logic, you get: Clear declarative rules A single observer watching multiple elements You describe what you care about, not how to calculate it.
Perfect for lazy loading

Common use cases:
Images/videos load only when near the viewport
Infinite scrolling
Initial page load time

Great for UI effects Use it for: Animations on scroll Revealing sections Highlighting nav items Tracking impressions (analytics)
Works asynchronously Runs off the main scroll event loop Won’t block rendering This is huge for complex or animation-heavy pages.

When not to use it

If you need pixel-perfect scroll positions
If you need to react to e very single scroll tick

Intersection Observer is about state changes, not continuous tracking.

how?

const observer = new IntersectionObserver(cb,options);

Step 1: Define the callback function that runs when an intersection occurs.

//cb
const handleIntersection (entries,observer) => {
// work with entries[]
// each entry you can get
- intersectionRatio (what percent of target element is visible on screen).
- isIntersecting (Boolean)
- target
// perform action - load an image, start an animation
// optional _ to stop observing observer.unobserve(entry.target);}

}

Step 2- Set options

options ={
root:null ( viewport or target ancestor),
rootMargin: ‘0px’,
threshold:0
}

rootMargin: To adjust viewport Area or we can say changes the trigger area.

rootMargin: “0px 0px 0px 0px” (top, right, bottom, left)

Threshold : when certain amount of target section is visible callback is executed.

Step 3- select the target element and start observing.

const targetElement = document.querySelector(…);
observer.observe(targetElement);

The Hidden Cost of Scroll Listeners

Chhavi Kohli — Sat, 24 Jan 2026 14:27:14 +0000

Is Your Scroll-Based Animation Killing Performance?

Chhavi Kohli ・ Jan 22

#javascript #performance #discuss #webapis

Is Your Scroll-Based Animation Killing Performance?

Chhavi Kohli — Thu, 22 Jan 2026 12:23:35 +0000

Still attaching scroll listeners to trigger animations or load content?
Here’s the practical, reliable way to ship smooth UIs at scale:
Intersection Observer

WHY?

The Hidden Cost of Scroll Listeners
At first glance, scroll listeners seem harmless.

You scroll → JavaScript runs → something animates.

The problem is how often that code runs.

Scroll Events Fire A Lot

When a user scrolls, the browser can fire the scroll event up to 60 times per second (once every frame).
That means your code is running:

While the browser is drawing pixels
While it’s calculating layouts
While it’s handling user input

Your scroll handler is now competing with the browser’s most time‑critical work.

Small Checks Can Trigger Big Work

element.getBoundingClientRect();

But under the hood, it may force the browser to:

Recalculate styles
Recompute layout
Flush the rendering pipeline

The Cost Grows with Every Element

If you check one element, it’s manageable.
If you check 10 elements, that work runs 10 times.
If you check 100 elements, the browser struggles.
This is why scroll‑based logic often feels fine at first……and suddenly becomes janky as the page grows.

Why Throttling Isn’t Enough:

“I’ll just throttle my scroll handler.”

Throttling helps reduce CPU usage, but it doesn’t fix everything:

Animations can fire late
Elements appear after they’re visible
Fast scrolling causes missed triggers
Touch scrolling still feels laggy

In other words: fewer explosions, same fire.

A Quick Performance Smell Test
Open Chrome DevTools → Performance, record a scroll, and look for:

Long “Event (scroll)” blocks
Frequent Layout or Recalculate Style steps

If you see them repeating during scroll, your page is doing too much work.

Key Takeaway

Scroll listeners aren’t bad because they’re wrong.

They’re bad because they make you do the browser’s job—over and over again.

That’s exactly the problem Intersection Observer was designed to solve.