DEV Community: Lalit

Rendering Massive Tables at Lightning Speed: Virtualization with Virtual Scrolling

Lalit — Mon, 13 Oct 2025 11:19:41 +0000

When building data-intensive applications - such as analytics, dashboards, admin panels, or log viewers - one of the toughest challenges is efficiently rendering very large tabular data in web browsers. Imagine a table with 100,000 rows and 50 columns - even a powerful device can stutter or freeze when trying to paint all of that to the DOM at once.

Existing libraries like react-window or react-virtualized do offer solutions through list virtualization and they are good. However, they often come with framework overhead, limited flexibility, and a layer of abstraction that hides how the optimization actually works which resist you to do more optimization as per your needs and use case.

In this article, I’ll walk you through how I built a high-performance tabular data viewer using Virtualization with Virtual Scrolling, written entirely in Vanilla JavaScript with TypeScript — no frameworks, no magic. This approach provides better control, leaner performance, and a deeper understanding of how browsers handle large DOM structures.

You can try out the live demo here 👉 Live Demo (Select csv file to test) and checkout full code on Github.

⚠️ Disclaimer:
This article focuses solely on the rendering techniques, not on client side data management strategies. Data fetching, caching, and server synchronization are separate architectural challenges that I'll may be cover in future discussions.

🧩 The Browser Rendering Pipeline — From HTML to Pixels

Before diving into virtualization or other optimization techniques, it’s important to understand how browsers handle rendering. A web page goes through several distinct stages before pixels appear on the screen:

1. HTML parsing -> DOM Tree Construction

The browser reads you HTML and builds a tree-like structure called the DOM (Document Object Model). Each tag becomes a node.

2. CSS Parsing -> CSSOM Tree

CSS rules are parsed into another structure, the CSS Object Model (CSSOM).

3. Render Tree constructed

The DOM and CSSOM are merged into the Render Tree, which represents what actually needs to be painted - including styles, layout, and visibility.

4. Layout (Reflow)

The browser calculates the size and position of every element. This step is expensive.

5. Painting

The bowser paints individual elements onto layers.

6. Compositing

Layers are combined to display the final frame on the screen.

As, it can be seen that there are multiple steps involved from HTML to pixels. So, when we render thousands of elements, this pipeline becomes overwhelmed - every element must be laid out, painted and composited. Even if most are offscreen, the browser doesn't know that - it still works on them.

That's where Virtualization comes in.

⚡ The Concept of Virtualization (and Virtual Scrolling)

Virtualization is the technique of rendering only what the user can see. Instead of mounting all 100,000 rows to the DOM, you render just a small window — say, 50 rows — corresponding to the visible area. As the user scrolls, you keep adding or replacing new.

In essence:

“You’re faking a long list, while actually maintaining only a handful of visible elements.”

🧠 Virtual Scrolling — The “Fake Scroll”

Traditional virtualization often uses a real scrollable container (overflow: auto), but this can be inefficient when the DOM is updated frequently. My approach goes one step further — a “virtual” scroll simulation:

The table container has a fixed height and overflow: hidden.
Instead of relying on native scroll behavior, we listen to wheel events.
Based on the scroll delta, we shift the data window (start and end indices).
The visible cells are updated using textContent (will talk about why I have used textContent) instead of re-creating DOM nodes.
A custom scrollbar reflects scroll position and allows direct navigation.
This can be done for both horizontal as well as vertical

So the browser only repaints the same number of cells repeatedly, while the illusion of scrolling is created by updating their text and adjusting a scrollbar thumb position.

Figure: Simplified View of Virtual Scrolling

Even if your dataset has 1 million rows, you’re only maintaining a constant number of DOM nodes.

🔍 Why I am using `textContent` to update the cells content

In this approach, each cell’s content is updated through:

cell.textContent = dataRow[columnIndex];

This choice may seem little, but it’s crucial for performance. That's why in the start of this article I have explained a bit of browser working. Let’s briefly compare the three main DOM update methods:

Method	Description	Performance
`innerHTML`	Parses HTML string and replaces all child nodes.	❌ Slow — triggers reflow and DOM reconstruction.
`innerText`	Sets or gets the rendered text (respects CSS).	⚠️ Slower — forces layout recalculation.
`textContent`	Sets text directly on node without layout changes.	✅ Fast — minimal reflow, ideal for frequent updates.

Since virtual scrolling updates cells many times per second, textContent, I my opinion, is by far the most efficient choice in our case.

🧰 Why Vanilla JavaScript?

It’s tempting to reach for React, especially with their ecosystem of virtualized table components. However, I have found in my working that framework abstractions some time introduce overhead — reconciliation, synthetic events, and VDOM diffing and cause performance decay (I could be wrong happy to be corrected).

By going framework-free, we gain:

Direct control over event handling and rendering cycles.
No diffing — updates happen instantly via textContent.
Smaller bundle size, faster startup.
Perfect for embedding in micro frontends or low-resource devices.

🧭 Custom Scrollbar for Navigation

Instead of a native scrollbar, the demo implements a fake scrollbar — a styled div (thumb) within a track. Moving the thumb calculates which data slice should be displayed.

This design decouples scrolling behavior from the browser’s default implementation, allowing you to fine-tune scroll speed, inertia etc.

It’s also visually customizable — an advantage for embedded analytics dashboards or custom-styled admin tools.

🧮 Optimization Layers

Beyond the virtualization concept itself, there are several smaller optimizations that help maintain performance. Lets see few of them, which I have found crucial.

requestAnimationFrame() for updates:
Defers updates to the next paint cycle to prevent layout thrashing.
debounce and throttle` utilities:
Common performance utilities as they will smooth out rapid input or scroll events.
Minimal reflows:
Important All rows and columns are fixed-size, avoid using min-width etc, use fixed size, so layout computation is predictable and cheap.
Data shape
I have found that data shape that you are using to loop over and render must be efficient to access.

💬 Note:
In this demo, all data resides in memory. Large-scale datasets typically require lazy loading or server-side pagination or even if large amount of data needs to be on client's device then must to be efficiently stored and handled, which will be discussed in future articles about data management.

💡 Needed more performance then use Canvas based Tables

While this virtual scrolling approach is extremely efficient, the DOM still carries certain overhead. Each cell is still an HTML element. When datasets reach millions of cells, even 50 visible rows × 50 columns = 2,500 active nodes can stress the layout engine.

If you require absolute maximum performance, the next logical step would a Canvas-based Table:

Each cell is drawn as text on a 2D <canvas> surface.
No DOM nodes — just pixels.
Google Sheets also uses this approach.

Ideal for real-time dashboards or data visualization systems.

I’ll cover this “Canvas Table” approach as well in my next article as well.

🚀 Closing Thoughts

Virtualization isn’t a new idea, it's been in there and users are using it, but that also sometimes require changes and optimizations to make it more efficient.

Stay tuned for my next article — “Rendering Millions of Cells with Canvas: Beyond the DOM” — where I’ll push this concept even further using Canvas based Table.

If you found this concept interesting and want to explore more, I’d love to connect!

You can follow me on LinkedIn, GitHub, and Twitter — I often share experiments, open-source work, and performance insights there.

If you're interested in contributing or collaborating on this, share ideas and suggestions, please feel free to reach out — let’s build something exciting together!

Adding Keyboard Shortcuts to Your React App in better way

Lalit — Sat, 30 Aug 2025 13:58:37 +0000

You might have seen some professional web apps like Google sheet, Figma or any other feature rich app. One thing that make these app's user experience better is use of keyboard interaction. You can also added these keyboard interactions in your react app. In this article, I will try to explain how you can build one in your app that will be cleaner, dev friendly and using best practices.

The Approach: A central Shortcut Manager

Imagine your app has a single, smart manager for all keyboard shortcuts. Its job is simple:

Listen to every key pressed anywhere in the app
Know all the available shortcuts and what they do
Ignore keys pressed in text (or editable) fields (a critical detail!)
Trigger the right action instantly

This is the core idea. Instead of having dozens of independent key listeners scattered across your components, you have one centralized brain with centralized registry of shortcuts. This makes everything easier: preventing conflicts, managing memory and keeping you code clean.

A Glimpse at the Implementation

This implementation will have two major part or files:

A Context Provider (ShortcutProvider): This component wraps you entire application. It becomes the central registry that holds all the shortcuts and their functions.
A Custom Hook (useShortcuts): This is how any component talks to the provider. It's simple API with two function: register and unregister. Which is simply like : "Hey manager, please register this shortcut for me and here is the function that I want to perform on triggering this shortcut" or "I am done with this shortcut, please unregister it."

Here is the beautiful part of using this pattern:

// Deep inside any component, you can easily add a shortcut.
function SaveButton() {
  const { register } = useShortcuts();

  // Register 'Ctrl+S' to save the document
  useEffect(() => {
    const handleSave = () => { /* Save logic here */ };
    register({ key: 's', modifiers: ['Ctrl'] }, handleSave);
    return () => unregister({ key: 's', modifiers: ['Meta']  }); // Cleanup!
  }, []);

Simple isn't, the component doesn't need to know about global event listeners and you can also add more rigorous conflict logic in "ShortcutProvider". It just asks the user component to register its intent. The central manager handles the rest.

The payoff: Why is it a better approach

Clear Code
Using best practice, react hook pattern with context
Team Friendly, as it creates a standard, simple way for everyone on you team to add and remove shortcuts without stepping on each other's toes.

Here is the full code :

`ShortcutsProvider.tsx`

"use client";
import React, { createContext, useEffect, useRef } from "react";
import {
  Modifier,
  Shortcut,
  ShortcutHandler,
  ShortcutRegistry,
  ShortcutsContextType,
} from "./types";

export const ShortcutsContext = createContext<ShortcutsContextType>({
  register: () => {},
  unregister: () => {},
});

const normalizeShortcut = (shortcut: Shortcut): string => {
  const mods = shortcut.modifiers?.slice().sort() || []; // Sort alphabetically
  const key = shortcut.key.toUpperCase(); // Normalize case
  return [...mods, key].join("+");
};

const ShortcutProvider = ({ children }: { children: React.ReactNode }) => {
  // Registry for shortcut with key as shortcut combination and value as the handler
  const ShortcutRegisteryRef = useRef<ShortcutRegistry>(new Map());

  const register = (
    shortcut: Shortcut,
    handler: ShortcutHandler,
    override = false
  ) => {
    const ShortcutRegistery = ShortcutRegisteryRef.current;
    // before proceeding with logic let normalized the key
    // first we sort the modifiers from shortcut alphabetically
    // then make key uppercase for consistency

    const modifiers = shortcut.modifiers
      ? shortcut.modifiers.slice().sort()
      : [];
    const key = shortcut.key.toUpperCase();

    const normalizedKey = [...modifiers, key].join("+");

    // here checking for conflicts
    if (ShortcutRegistery.has(normalizedKey) && !override) {
      console.warn(
        `Conflict: "${normalizedKey}" is already registered for shortcut. Use override=true to replace or handle conflict.`
      );
      return;
    }

    ShortcutRegistery.set(normalizedKey, handler);
  };

  const unregister = (shortcut: Shortcut) => {
    // again normaizing the key, we are repeating this code so better to make function out of this
    const modifiers = shortcut.modifiers
      ? shortcut.modifiers.slice().sort()
      : [];
    const key = shortcut.key.toUpperCase();

    const normalizedKey = [...modifiers, key].join("+");
    ShortcutRegisteryRef.current.delete(normalizedKey);
  };

  const handleKeyDown = (event: KeyboardEvent) => {
    const target = event.target as HTMLElement;
    // this check is important as without this we wont be able to write in these inputs
    if (
      target.tagName === "INPUT" ||
      target.tagName === "TEXTAREA" ||
      target.isContentEditable
    ) {
      return;
    }

    const modifiers: Modifier[] = [];

    if (event.ctrlKey) modifiers.push("Ctrl");
    if (event.altKey) modifiers.push("Alt");
    if (event.shiftKey) modifiers.push("Shift");
    if (event.metaKey) modifiers.push("Meta");

    const key = event.key.toUpperCase();
    const normalizedKey = [...modifiers.sort(), key].join("+");

    const handler = ShortcutRegisteryRef.current.get(normalizedKey);

    if (handler) {
      event.preventDefault();
      handler(event);
    }
  };

  useEffect(() => {
    window.addEventListener("keydown", handleKeyDown);
    return () => window.removeEventListener("keydown", handleKeyDown);
  }, []);

  return (
    <ShortcutsContext.Provider value={{ register, unregister }}>
      {children}
    </ShortcutsContext.Provider>
  );
};

export default ShortcutProvider;

`useShortcuts.tsx`

import { useContext } from "react";
import { ShortcutsContext } from "./ShortcutsProvider";

const useShortcuts = () => {
  const shortcutContext = useContext(ShortcutsContext);

  if (!shortcutContext) {
    console.error("Shortcut context must be wrapped inside Shortcut provider");
  }

  return shortcutContext;
};

export default useShortcuts;

`types.ts`

export type Modifier = string;
export type Key = string;

export interface Shortcut {
  key: Key;
  modifiers?: string[];
}

export type ShortcutHandler = (e: KeyboardEvent) => void;
export interface ShortcutsContextType {
  register: (shortcut: Shortcut, handler: ShortcutHandler) => void;
  unregister: (shortcut: Shortcut) => void;
}

export type ShortcutRegistry = Map<string, ShortcutHandler>;

Main app component (using Next js here)

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body
        className={`${geistSans.variable} ${geistMono.variable} antialiased`}
      >
        <ShortcutProvider>{children}</ShortcutProvider>
      </body>
    </html>
  );
}

You can find the complete solution with workable example on GitHub.

Let's Connect!

Enjoyed this breakdown? I share tips and insights on social media platforms. Follow me on X/Twitter. Feel free to star the project on GitHub and connect with me on LinkedIn.

Optimal State Management Strategy for React: A Practical Three-Tiered Approach

Lalit — Wed, 20 Aug 2025 10:21:40 +0000

As React applications grow in complexity, one of the most critical challenges developers face is effective state management. Through my experience designing and building React applications, I've refined a strategic approach that balances simplicity, scalability, and developer experience.

In this article, I'll share my three-tiered strategy for state management, which combines global libraries (like Redux or Zustand), React Context for semi-local state, and the built-in useState/useReducer hooks for local state.

This methodology was forged in the fires of a real-world project: a heavy-data Management System frontend. The application, packed with complex tables, frequently updated datasets, and intricate forms, demanded a solution that was both robust and maintainable. The strategy I developed to meet those demands is what I'll outline for you today.

The Three-Tiered Approach

The strategy is simple and follows a clear hierarchy:

Global State (like Redux, Zustland or any other of your choice): Application-wide data that needs to be accessed across the app
Semi-Local State (Context): Data shared within a specific section of the application
Local State (useState/useReducer): Component-specific state that doesn't need to be shared

Ok, lets dive little deeper

First tier of the three tier approach is Global State.

This will the global store for application-wide state that needs to be accessed from various components across the app, here we also store our fetched data. For example fetching and storing data of our Management system I talked about earlier (Libraries like React Query or SWR are excellent choices for handling server-state fetching, caching, and synchronization, often reducing or even eliminating the need for a traditional global store for this type of data). For this we can use a state management library. While Redux has been the traditional choice, I personally prefer Zustand for its simplicity and minimal boilerplate. However, both are excellent choices depending on your needs and preferences.

Little code example:

In this example we are fetching leads and storing and showing on page using table.

import create from 'zustand';

const useLeadStore = create((set) => ({
  leads: {},
  leadIds: [],
  loading: false,
  error: null,

  // Fetch leads from API and store them
  fetchLeads: async (apiUrl) => {
    set({ loading: true, error: null });
    try {
      const response = await fetch(apiUrl);
      if (!response.ok) throw new Error('Failed to fetch leads');
      const data = await response.json();

      // Assuming data is an array of leads
      set((state) => {
        const leads = { ...state.leads };
        const leadIds = new Set(state.leadIds);

        data.forEach((lead) => {
          leads[lead.id] = lead;
          leadIds.add(lead.id);
        });

        return {
          leads,
          leadIds: Array.from(leadIds),
          loading: false,
        };
      });
    } catch (error) {
      set({ loading: false, error: error.message });
    }
  },

// you can also have more functions like updating, removing etc.

  clearLeads: () => set({ leads: {}, leadIds: [] }),
}));

export default useLeadStore;

Another example, is auth, used all over the app

import create from 'zustand';

const useAuthStore = create((set) => ({
  user: null,          // User information object
  loading: false,
  error: null,

  // Login action
  login: async (credentials, loginApi) => {
    set({ loading: true, error: null });
    try {
      const response = await fetch(loginApi, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(credentials),
      });
      if (!response.ok) throw new Error('Login failed');
      const data = await response.json();

      set({
        user: data.user,
        loading: false,
        error: null,
      });
    } catch (error) {
      set({
        loading: false,
        error: error.message,
      });
    }
  },

  // Logout action
  logout: () => set({ user: null, token: null, error: null }),

  // Check if user is authenticated
  isAuthenticated: () => Boolean(get().token),
}));

export default useAuthStore;

I think from these example you might get a clear picture what I want to say.

Second tier of the three is Semi-Local State with Context

For state that needs to be shared within a specific part of your application (like a form, a set of related components, or a feature module) or DOM tree, React Context is the perfect solution. It avoids polluting the global store while providing easy access to shared state within a defined scope and also can help me avoiding ugly prop drills.

A good example for this is to manage column resizing and freezing provides a clean way to share and update this UI state within the table component tree without cluttering global state or passing props through multiple levels. The context holds the current column widths and frozen columns, along with functions to update these. This allows any header or cell component within the provider to access and modify the resizing and freezing logic seamlessly, enabling coordinated UI behavior and avoiding prop drilling.

import React, { createContext, useContext, useState } from 'react';

const ColumnContext = createContext();

export function ColumnProvider({ children }) {
  const [columnWidths, setColumnWidths] = useState({}); // { colId: width }
  const [frozenColumns, setFrozenColumns] = useState(new Set()); // Set of frozen colIds

  const resizeColumn = (colId, width) => {
    setColumnWidths((prev) => ({ ...prev, [colId]: width }));
  };

  const toggleFreeze = (colId) => {
    setFrozenColumns((prev) => {
      const updated = new Set(prev);
      if (updated.has(colId)) updated.delete(colId);
      else updated.add(colId);
      return updated;
    });
  };

  return (
    <ColumnContext.Provider
      value={{ columnWidths, frozenColumns, resizeColumn, toggleFreeze }}
    >
      {children}
    </ColumnContext.Provider>
  );
}

export function useColumnContext() {
  return useContext(ColumnContext);
}

Third and final tier of three is Local State with useState/useReducer

For state that's truly local to a single component (or a small set of tightly coupled components), we can simple use useState or useReducer, which ever suits your use case. For example, form inputs, or any data that doesn't need to be shared across the application.

Why this approach could be a better one

Performance: Components only subscribe to the state they need
Separation of Concerns: Different types of state have clear homes
Maintainability: The purpose of each state is immediately clear
Scalability: Easy to refactor as requirements change

Common Pitfalls to Avoid

Don't put everything in global state "just in case"
Avoid creating Context for every small piece of state—it can make your component tree messy
Remember that global state and Context are not mutually exclusive—they can work together
You need to find the optimal boundary for diving the state.

Final thoughts

By strategically implementing this three-tiered approach—global libraries for app-wide data, Context for feature-specific state, and use state for local UI concerns—you can build React applications that are not only highly performant but also maintainable and scalable.

If you found this article helpful, feel free to:

Follow me on GitHub for more code examples and projects: Github
Connect with me on LinkedIn to discuss all things React and frontend development: Linkedin

Happy coding

Lets master sliding window pattern: an essential DSA technique

Lalit — Sat, 16 Aug 2025 14:16:41 +0000

Welcome the first post of the our full series of DSA for Frontend Engineer (But I guess it will be useful for all developers). Today, we are diving into simple, yet powerful and very useful technique called Sliding window. This technique is lifesaver for solving problems that involve finding and optimal subarray, substring or subsequence with larger data set.

So, what is Sliding Window pattern?

Imagine you are at a school assembly, and your job is to find the 10 students in a row who have the height total height.

A brute force approach would be pick the first 10 students, measure their total height, then move to the next group of 10(starting from the second student) and measure their total height from scratch, and so on. This would be a lot of repetitive work.

A sliding window approach is much smarter this brute force approach. You would first measure the total height of the first group of 10 students. To find the total height of the next group of 10(students 2 through 11), you don't start over. Instead, you simply subtract the height of the first student (who is now out the group) and add the height of the 11 th student (who is not in the group). You have effectively 'move' or 'slide' your window of 10 students one spot to the right, and you did it with just two quick calculations instead of ten.

This simple optimization is what makes the pattern so powerful. By reusing the information from the previous window, it significantly reduces the no. of operations needed to solve a problem. Often improving the time complexity from an inefficient O(n²) to must faster O(n).

Lets take some example to understand it better

We will try to understand using 5 examples by getting intuition and approach and data structure used.

Problem	LeetCode #	Technique Used or DS used	Key Insight	Solution Link
Longest Substring Without Repeating Characters	3	Hash Set + Two Pointers	Maintain window of unique characters using set	View Solution
Minimum Window Substring	76	Frequency Map + Counter	Expand right until valid, then shrink left	View Solution
Subarray Product Less Than K	713	Dynamic Window + Running Product	Adjust window based on current product	View Solution
Sliding Window Maximum	239	Monotonic Deque	Maintain decreasing order in deque	View Solution
Minimum Size Subarray Sum	209	Dynamic Window + Prefix Sum	Expand right, shrink left when sum ≥ target	View Solution

🚀 Problem Catalog

Problem Name	LC #	Difficulty	Key Technique	Window Type	Time Complexity
Permutation in String	567	Medium	Frequency Array	Fixed	O(n)
Fruit Into Baskets	904	Medium	Hash Map	Dynamic	O(n)
Max Consecutive Ones III	1004	Medium	Zero Counter	Dynamic	O(n)
Sliding Window Maximum	239	Hard	Monotonic Deque	Fixed	O(n)
Minimum Window Substring	76	Hard	Frequency Map	Dynamic	O(n)
Longest Repeating Character Replacement	424	Medium	Frequency Count	Dynamic	O(n)
Subarray Product Less Than K	713	Medium	Running Product	Dynamic	O(n)
Find All Anagrams in a String	438	Medium	Frequency Array	Fixed	O(n)

🔑 Pattern Cheat Sheet

Fixed Window:

Constant size (#239, #567, #438)
Template:

 for (let i = 0; i <= nums.length - k; i++) {
     // Process window [i, i+k-1]
 }

Dynamic Window:

Flexible size (#3, #76, #209)
Template:

 while (right < nums.length) {
     // Expand window
     while (invalid) {
         // Shrink window
     }
     // Update answer
 }

Hybrid Techniques:
- Frequency maps (#76, #567)
- Monotonic queues (#239)
- Prefix sums (#209)

📈 Recommended Practice Order

Start with #3 → #209 → #567 (basic patterns)
Advance to #904 → #1004 → #424 (intermediate)
Master #239 → #76 → #713 (advanced)

Pro Tip: Focus on identifying the "window validity condition" first in each problem!

Wrapping Up 🚀

The sliding window technique is one of those must-have tools in every developer's DSA toolkit. As we've seen through these examples:

✔ Efficiency Boost: Turns O(n²) problems into O(n) magic

✔ Real-World Relevance: From string manipulation to array analysis

✔ Pattern Versatility: Adaptable to counting, summing, and max/min problems

Found this helpful?

👉 Star the GitHub repo to bookmark these solutions

👉 Share with your coding buddies who are prepping for interviews

👉 Leave a comment with your favorite sliding window problem!

🤖 This article has been assisted by AI | Try using AI to practice problem and ace interviews, not only interviews, to become a better software engineer

Double Ended Queue: More Than Just a Queue

Lalit — Sat, 16 Aug 2025 12:27:15 +0000

Alright, so I was grinding some LeetCode problems (as one does) and in one of a problem I saw this pattern—Double Ended Queue or Deque (pronounced "deck," not "dee-queue," learned that the hard way 😅). At first, I was like, "Why not just use a normal queue or a stack?" But turns out, deques are game changer for certain problems. So, let’s break it down—what it is, how to implement it (in TypeScript, you can use your fav language), and where it uses in DSA.

What’s a Deque?

A Deque is like a queue, but with some more powers. In a normal queue, you can only add to the back (enqueue) and remove from the front (dequeue). But a deque lets you add/remove from both ends. Think of it as a hybrid between a stack (LIFO) and a queue (FIFO).

Operations:

pushFront(x): Add x to the front.
pushBack(x): Add x to the back.
popFront(): Remove from the front.
popBack(): Remove from the back.
peekFront(): Get front element.
peekBack(): Get back element.

Implementing a Deque in TypeScript

class DequeNode<T> {
    value: T;
    next: DequeNode<T> | null;
    prev: DequeNode<T> | null;

    constructor(value: T) {
        this.value = value;
        this.next = null;
        this.prev = null;
    }
}

class Deque<T> {
    private front: DequeNode<T> | null;
    private back: DequeNode<T> | null;
    private size: number;

    constructor() {
        this.front = null;
        this.back = null;
        this.size = 0;
    }

    pushFront(value: T): void {
        const newNode = new DequeNode(value);
        if (this.size === 0) {
            this.front = newNode;
            this.back = newNode;
        } else {
            newNode.next = this.front;
            this.front!.prev = newNode;
            this.front = newNode;
        }
        this.size++;
    }

    pushBack(value: T): void {
        const newNode = new DequeNode(value);
        if (this.size === 0) {
            this.front = newNode;
            this.back = newNode;
        } else {
            newNode.prev = this.back;
            this.back!.next = newNode;
            this.back = newNode;
        }
        this.size++;
    }

    popFront(): T | null {
        if (this.size === 0) return null;
        const value = this.front!.value;
        this.front = this.front!.next;
        if (this.front) {
            this.front.prev = null;
        } else {
            this.back = null; // deque is now empty
        }
        this.size--;
        return value;
    }

    popBack(): T | null {
        if (this.size === 0) return null;
        const value = this.back!.value;
        this.back = this.back!.prev;
        if (this.back) {
            this.back.next = null;
        } else {
            this.front = null; // deque is now empty
        }
        this.size--;
        return value;
    }

    peekFront(): T | null {
        return this.front?.value ?? null;
    }

    peekBack(): T | null {
        return this.back?.value ?? null;
    }

    getSize(): number {
        return this.size;
    }

    isEmpty(): boolean {
        return this.size === 0;
    }
}

Why Not Just Use an Array?

In JS/TS, arrays already support push, pop, shift, and unshift, so you could use an array as a deque. But shift and unshift are O(n) operations because they require reindexing. A proper deque implementation (like above) must does everything in O(1).

Uses in DSA

Lets see the question where I have found this pattern use full.

Sliding Window Maximum (LeetCode 239)

Alright, here’s where deques shine. The problem:

Given an array nums and a window size k, return an array of the maximum in each sliding window.

Brute Force (O(n*k)):

For each window, scan all k elements to find the max. Works, but slow for large n.

Optimal (O(n)):

Use a monotonic deque to keep track of potential max candidates.

How it works:

The deque stores indices (not values) in decreasing order of their values.
For each new element, remove indices from the back if their values are ≤ current element (since they’ll never be the max in any future window).
The front of the deque is always the max of the current window.
Remove elements from the front if they’re outside the current window.

TypeScript Solution:

function maxSlidingWindow(nums: number[], k: number): number[] {
    const result: number[] = [];
    const deque: number[] = []; // stores indices

    for (let i = 0; i < nums.length; i++) {
        // Remove indices outside the current window
        if (deque.length > 0 && deque[0] === i - k) {
            deque.shift();
        }

        // Remove indices from the back whose values are <= nums[i]
        while (deque.length > 0 && nums[deque[deque.length - 1]] <= nums[i]) {
            deque.pop();
        }

        deque.push(i);

        // The front is the max for the current window
        if (i >= k - 1) {
            result.push(nums[deque[0]]);
        }
    }

    return result;
}

Why This Works:

The deque maintains elements in decreasing order, so the front is always the max.
By removing smaller elements before adding new ones, we ensure only relevant candidates remain.
Each element is added and removed at most once, so O(n) time.

Other Uses of Deque:

Palindrome Checker: Push front and back, then compare.
BFS with Level Tracking: Sometimes used in tree traversals.
Undo/Redo Operations: Deques can manage history stacks.

Final Thoughts

Deques are super versatile and powerful data structure. They’re not just a fancy queue—they’re a powerhouse for sliding window problems and other scenarios where you need O(1) ops at both ends.

Next time you see a problem with sliding windows or max/min in subarrays, think DEQUE! 🚀

Like this breakdown?
👉 Follow for more DSA deep-dives!
👉 Drop a comment if anything you want to share.
👉 Share with your coding buddy who’s stuck on the problem that can be solved using this.

Rethinking the Virtual DOM: A Case for Direct DOM Manipulation in Modern Web Development

Lalit — Thu, 29 May 2025 05:56:33 +0000

For so long, the Virtual DOM has been the principal innovation powering React and other modern UI libraries. By abstracting away real DOM mutations, it enabled developers to describe UI in a declarative manner, reducing the need for manual DOM interactions and often improving performance.

However, in 2025, it's time to ask: Is the Virtual DOM still the best approach for all cases?

In this post, I’ll explore why direct DOM manipulation is making a comeback, especially in performance-critical and modern UI scenarios—and why we shouldn’t shy away from it.

🧭 Why Was the Virtual DOM Introduced?

In the early 2010s, as more and more web page started to become web app the frequent DOM manipulation was required and manipulating the DOM directly was slow and expensive.

Browser engines weren't optimized for frequent, granular updates.
Layout recalculations and repaints triggered performance bottlenecks.
Managing state manually across DOM nodes was very difficult and hard-to-maintain codebases.

The Virtual DOM was introduced as a smart layer of abstraction that minimized direct interaction with the DOM, computed diffs efficiently in memory, and batched real DOM updates in a performant way.

It was a very good idea.

🚀 But the Web Has Changed

Lets move ours self today :

Modern browsers (Chrome, Safari, Firefox, Edge) have significantly optimized their DOM engines.
Hardware acceleration and fast JavaScript runtimes make DOM manipulation less of a bottleneck.
Techniques like MutationObserver, requestIdleCallback, and IntersectionObserver provide efficient hooks into the DOM lifecycle.

As a result, many of the performance issues that justified the VDOM in the past are now less relevant—especially for micro-interactions and small-scale updates.

Then the question arises: Do we still need the Virtual DOM for everything?

💡 The Case for Direct DOM Manipulation

With browser advancements, direct DOM manipulation is no longer the performance villain it once was. In fact, for specific use cases, it can offer significant advantages:

Finer-Grained Control: When you need absolute control over every pixel or specific timing for animations, transitions, or complex canvas interactions, direct DOM manipulation allows for precise adjustments that a VDOM abstraction might obscure or make less efficient.
Reduced Overhead: Libraries like React and Vue come with a certain bundle size and runtime overhead due to the VDOM reconciliation process. For smaller, highly optimized components or micro-frontends, bypassing the VDOM can lead to significantly smaller JavaScript payloads and faster initial load times.
Performance-Critical Scenarios: Think about high-frequency updates in games, data visualizations (e.g., D3.js), or real-time dashboards. In these cases, direct manipulation can often outperform VDOM-based updates because you can directly target and update only the necessary elements without the diffing algorithm overhead.
Simpler Debugging for Specific Changes: When you're directly manipulating the DOM, the link between your code and the visible change is immediate and explicit. This can sometimes simplify debugging for very specific, localized UI updates, as there's no intermediate abstraction layer to consider.
Leveraging Web Components: The rise of Web Components (Custom Elements, Shadow DOM) encourages a more direct, encapsulated approach to UI development, often without the need for a heavy framework. These components naturally interact with the DOM directly, promoting a modular and performant architecture.

🤔 When Virtual DOM Still Shines

It's crucial to understand that advocating for direct DOM manipulation doesn't mean abandoning the Virtual DOM entirely. It still holds immense value in many scenarios:

Complex, State-Driven Applications: For large-scale applications with intricate state management and unpredictable UI changes, the declarative nature of VDOM libraries (like React) remains incredibly powerful. Developers can focus on "what" the UI should look like based on state, rather than "how" to update the DOM.
Developer Experience and Productivity: The declarative paradigm, component-based architecture, and rich ecosystems built around VDOM libraries significantly boost developer productivity, especially for teams working on large projects.
Cross-Browser Consistency: VDOM libraries abstract away many browser inconsistencies, providing a more uniform development experience and reducing the need for manual browser-specific fixes.
Server-Side Rendering (SSR) and Hydration: VDOM-based frameworks are well-suited for SSR, which improves initial page load performance and SEO by rendering UI on the server and then "hydrating" it on the client.

⚖️ A Balanced Approach for 2025

In 2025, the conversation isn't about choosing one over the other, but rather understanding when to use which tool.

For highly interactive, performance-critical, or small-scale components, consider direct DOM manipulation, perhaps within the context of Web Components or vanilla JavaScript.

For large, complex applications with rapidly changing data and a need for declarative UI, Virtual DOM-based frameworks continue to be an excellent choice.

Modern web development is about pragmatism. Developers should feel empowered to use the most appropriate tool for the job, combining the strengths of declarative frameworks with the precision and performance benefits of direct DOM manipulation where it makes sense. This hybrid approach allows us to build web experiences that are both powerful and incredibly performant.

The Virtual DOM was a brilliant innovation that solved critical problems of its time. But as the web evolves, so too should our understanding of its best practices. Embracing direct DOM manipulation for specific use cases isn't a step backward; it's a strategic move forward, enabling us to unlock new levels of performance and control in modern web applications.

Tired of Ternary Hell? Clean Up Your React Conditionals with react-if-then-else-switch

Lalit — Thu, 29 May 2025 05:47:43 +0000

As React developers, we spend a good chunk of our time rendering components conditionally. While JSX's built-in && operator and ternary ? : are powerful, they can quickly lead to deeply nested, unreadable code. We've all been there: a screen full of ? : that looks more like a syntax puzzle than a clear UI definition.

The Problem: When Conditionals Get Messy

Consider a common scenario where you need to render different content based on a user's role:

// The dreaded nested ternary operator
{user.isAdmin ? (
  <AdminDashboard />
) : user.isEditor ? (
  <EditorPanel />
) : user.isLoggedIn ? (
  <UserProfile />
) : (
  <LoginPage />
)}

Or perhaps a complex && chain for multiple conditions:

// Verbose && chains
{user.hasPermission && user.isActive && !user.isSuspended && (
  <div>
    <h2>Welcome!</h2>
    <p>You have access to premium features.</p>
  </div>
)}

While functional, these patterns often sacrifice readability, especially as your application grows. They don't clearly convey the "if this, else if that, else something else" flow that we're so used to from traditional programming languages.

The Solution: Declarative Conditionals with `react-if-then-else-switch`

This is where react-if-then-else-switch steps in. As the creator of this lightweight React library, my aim was to bring a more declarative, readable, and structured approach to conditional rendering. Inspired by classic if/else if/else and switch/case statements, it allows you to express your UI logic in a way that feels natural and intuitive.

Say hello to cleaner JSX:

IfElse for sequential conditions:

import { IfElse, If, ElIf, Else } from 'react-if-then-else-switch';

function UserAccess({ user }) {
  return (
    <IfElse>
      <If condition={user.isAdmin}>
        <AdminDashboard />
      </If>
      <ElIf condition={user.isEditor}>
        <EditorPanel />
      </ElIf>
      <ElIf condition={user.isLoggedIn}>
        <UserProfile />
      </ElIf>
      <Else>
        <LoginPage />
      </Else>
    </IfElse>
  );
}

Doesn't that just read better? You can immediately grasp the flow of logic.

Switchfor value-based matching:

import { Switch, Case, Default } from 'react-if-then-else-switch';

function FeatureDisplay({ featureFlag }) {
  return (
    <Switch value={featureFlag}>
      <Case when="darkMode">
        <ThemeToggle isDark={true} />
      </Case>
      <Case when="notifications">
        <NotificationSettings />
      </Case>
      <Default>
        <ComingSoonMessage />
      </Default>
    </Switch>
  );
}

This brings the clarity of a switch statement directly into your JSX, making it incredibly clear which content renders for specific values.

✨ Key Features at a Glance:

<IfElse> Wrapper: The central orchestrator for If, ElIf, and Else.
<If>: Your primary condition.
<ElIf>: For "else if" scenarios, evaluated only if preceding conditions are false.
<Else>: The ultimate fallback if no If or ElIf condition is met.
<Switch>: Match a value against various Case components.
<Case>: Renders if its when prop matches the parent Switch's value.
<Default>: The fallback for Switch if no Case matche s.

📦 Get Started Today!

Ready to clean up your React code? Install react-if-then-else-switch in your project:

npm install react-if-then-else-switch
# OR
yarn add react-if-then-else-switch

📚 Dive Deeper & Explore Demos

For detailed documentation, more examples, and interactive live demos, check out our project's page:

👉 View Documentation & Live Demos Here 👈

react-if-then-else-switch is an open-source project. I invite you to explore it, use it in your projects, and contribute! Your feedback and ideas are invaluable. Feel free to raise issues or submit pull requests on our GitHub Repository.

Happy coding!

Creating a Scrollable Table with a Sticky Header and Frozen Column Using HTML and CSS only

Lalit — Sun, 22 Dec 2024 10:44:48 +0000

Tables are fundamental in web applications for displaying structured data. Adding features like a scrollable header and frozen (sticky) columns can make tables even more user-friendly. In this article, we’ll explore how to create a table with a sticky header and a frozen left column using pure HTML and CSS.

CodePen Example

To see the code in action, check out this live example on CodePen:
This example of code uses JS class to make a table. You can replicate this with any framework or library of your choice.

Key Features of the Table

Sticky Header: The table’s header stays visible at the top when scrolling vertically.
Frozen Left Column: The first column remains fixed as you scroll horizontally.
Scrollable Content: Both vertical and horizontal scrolling are supported.
Customizable Styles: The table design is clean and modern, with zebra striping and hover effects.

HTML Structure

We use a simple table structure with a <thead> for the header and a <tbody> for the rows. The table is wrapped in a div for scrollability. Here's the code:

<div class="table-container">
  <table class="table">
    <thead>
      <tr>
        <th>Name</th>
        <th>Age</th>
        <th>Email</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>John Doe</td>
        <td>25</td>
        <td>john.doe@example.com</td>
      </tr>
      <tr>
        <td>Jane Smith</td>
        <td>30</td>
        <td>jane.smith@example.com</td>
      </tr>
      <!-- Additional rows can go here -->
    </tbody>
  </table>
</div>

CSS for Sticky Header and Frozen Column

Here’s the CSS that makes the magic happen:

/* General styles */
body {
  font-family: Arial, sans-serif;
}

/* Scrollable container */
.table-container {
  border: 1px solid #e5e7eb;
  border-bottom: none;
  overflow: auto; /* Enables both horizontal and vertical scrolling */
  height: 400px; /* Limits table height for vertical scrolling */
}

/* Table layout */
.table {
  border-collapse: collapse;
  width: 100%;
  table-layout: fixed; /* Ensures consistent column widths */
}

/* Table cells and headers */
.table th,
.table td {
  padding: 8px;
  text-align: center;
  border: 1px solid #e5e7eb;
}

/* Frozen first column */
.table td:nth-child(1),
.table th:nth-child(1) {
  background: red; /* Highlighted background for frozen column */
  position: sticky;
  left: 0; /* Ensures the column stays on the left */
  z-index: 5; /* Keeps the column above other cells */
  color: white;
}

/* Add higher z-index for header */
.table th:nth-child(1) {
  z-index: 6;
}

/* Sticky header */
.table th {
  background-color: #1e3a8a;
  color: white;
  font-size: 14px;
  font-weight: bold;
  position: sticky;
  top: 0; /* Makes the header stick to the top */
  z-index: 2; /* Keeps the header above the table body */
}

/* Styling for table body */
.table td {
  font-size: 14px;
  color: #6b7280;
}

/* Zebra striping for rows */
.table tr:nth-child(odd) {
  background-color: #f9fafb;
}

/* Hover effect for rows */
.table tr:hover {
  background-color: rgba(14, 116, 144, 0.1);
}

/* No data row styling */
.no-data {
  text-align: center;
  font-size: 14px;
  color: #9ca3af;
}

Explaining the CSS

Scrollable Container:

The .table-container class adds overflow: auto to enable both horizontal and vertical scrolling. The height: 400px property limits the height of the table, ensuring vertical scrolling for larger datasets.

Sticky Header:

The position: sticky and top: 0 properties are applied to <th>elements to ensure the header remains visible during vertical scrolling.
z-index: 2 ensures the header is displayed above the table body.

Frozen Left Column:

The first column is styled using nth-child(1) selectors for <td> and <th>.
The position: sticky and left: 0 properties ensure the column stays in place while scrolling horizontally.
The z-index values differentiate the column’s cell (5) and header (6) to ensure proper layering.

Highlighting Frozen Column:

The background color for the frozen column is set to red, with white text for better visibility. You can customize this to match your design preferences.

How It Works Together

As you scroll vertically, the position: sticky header remains at the top of the .table-container.
When scrolling horizontally, the leftmost column remains fixed, creating a frozen column effect.
The combination of overflow: auto and position: sticky ensures the table remains functional and user-friendly across both axes.

Enhancements You Can Add

Responsive Adjustments:

Use media queries to adjust the column widths and table layout for smaller screens.

Dynamic Content Loading:

Use JavaScript to fetch and populate rows dynamically for larger datasets.

Interactive Features:

Add row click events, filtering, or sorting using JavaScript to enhance functionality.

Final Thoughts

Using the standard <table> element and a few lines of CSS, we’ve created a powerful, responsive table with a sticky header and a frozen left column. This approach is lightweight, easy to implement, and works seamlessly across modern browsers.

Whether you're building dashboards, displaying reports, or handling large datasets, this method ensures a clean and professional design that’s also user-friendly. Try it out and let me know how it works for your project! 😊

If you found this helpful, consider connecting with me to read more useful article like this. You can find me on LinkedIn and GitHub, where I share insights and updates.

DEV Community: Lalit

Rendering Massive Tables at Lightning Speed: Virtualization with Virtual Scrolling

🧩 The Browser Rendering Pipeline — From HTML to Pixels

1. HTML parsing -> DOM Tree Construction

2. CSS Parsing -> CSSOM Tree

3. Render Tree constructed

4. Layout (Reflow)

5. Painting

6. Compositing

⚡ The Concept of Virtualization (and Virtual Scrolling)

🧠 Virtual Scrolling — The “Fake Scroll”

Figure: Simplified View of Virtual Scrolling

🔍 Why I am using textContent to update the cells content

🧰 Why Vanilla JavaScript?

🧭 Custom Scrollbar for Navigation

🧮 Optimization Layers

💡 Needed more performance then use Canvas based Tables

🚀 Closing Thoughts

Adding Keyboard Shortcuts to Your React App in better way

The Approach: A central Shortcut Manager

A Glimpse at the Implementation

Here is the beautiful part of using this pattern:

The payoff: Why is it a better approach

Here is the full code :

ShortcutsProvider.tsx

useShortcuts.tsx

types.ts

Main app component (using Next js here)

Let's Connect!

Optimal State Management Strategy for React: A Practical Three-Tiered Approach

The Three-Tiered Approach

Ok, lets dive little deeper

First tier of the three tier approach is Global State.

Little code example:

Second tier of the three is Semi-Local State with Context

Third and final tier of three is Local State with useState/useReducer

Why this approach could be a better one

Common Pitfalls to Avoid

Final thoughts

If you found this article helpful, feel free to:

Lets master sliding window pattern: an essential DSA technique

So, what is Sliding Window pattern?

Lets take some example to understand it better

🚀 Problem Catalog

🔑 Pattern Cheat Sheet

📈 Recommended Practice Order

Wrapping Up 🚀

Double Ended Queue: More Than Just a Queue

What’s a Deque?

Operations:

Implementing a Deque in TypeScript

Why Not Just Use an Array?

Uses in DSA

Sliding Window Maximum (LeetCode 239)

Brute Force (O(n*k)):

Optimal (O(n)):

How it works:

TypeScript Solution:

Why This Works:

Other Uses of Deque:

Final Thoughts

Rethinking the Virtual DOM: A Case for Direct DOM Manipulation in Modern Web Development

🧭 Why Was the Virtual DOM Introduced?

🚀 But the Web Has Changed

💡 The Case for Direct DOM Manipulation

🤔 When Virtual DOM Still Shines

⚖️ A Balanced Approach for 2025

Tired of Ternary Hell? Clean Up Your React Conditionals with react-if-then-else-switch

The Problem: When Conditionals Get Messy

The Solution: Declarative Conditionals with react-if-then-else-switch

Say hello to cleaner JSX:

✨ Key Features at a Glance:

📦 Get Started Today!

📚 Dive Deeper & Explore Demos

Creating a Scrollable Table with a Sticky Header and Frozen Column Using HTML and CSS only

CodePen Example

Key Features of the Table

HTML Structure

CSS for Sticky Header and Frozen Column

Explaining the CSS

🔍 Why I am using `textContent` to update the cells content

`ShortcutsProvider.tsx`

`useShortcuts.tsx`

`types.ts`

The Solution: Declarative Conditionals with `react-if-then-else-switch`