DEV Community: YT Low

List Virtualization — How to Render 100,000 Rows Without Killing Your Browser

YT Low — Sun, 06 Sep 2026 02:12:37 +0000

Full guide with a live 100,000-row demo, step-by-step code, and library comparison on onlyWebPro.

Throw 50,000 <div>s at a browser and watch it choke.

A list of 50,000 items with no virtualization: ~850MB of DOM. The same list with virtualization: ~1.2MB. Same data. Same scroll experience. Completely different DOM cost.

Here's how the technique works — in 7 steps, plain JavaScript, no library.

The core idea

Only create real DOM elements for the rows the user can actually see — typically 15–20 at any time. Everything else stays as plain JavaScript data. As the user scrolls, you reuse those same elements, update their content, and reposition them. No creating or destroying thousands of nodes.

The 7 steps

Step 1 — Scrollable container
A fixed-height div with overflow-y: auto and position: relative. This is the viewport the user scrolls inside.

Step 2 — The spacer (the non-obvious one)
If you only put 15 real rows inside the container, the scrollbar thinks the list is tiny. Fix: add one invisible div whose height equals total items × row height. It takes up space without rendering anything. The scrollbar now correctly represents 50,000 rows.

Step 3 — The maths
scrollTop / ITEM_HEIGHT tells you which row is at the top of the screen. containerHeight / ITEM_HEIGHT tells you how many rows fit. That's your visible range.

function getVisibleRange(scrollTop, containerHeight) {
  const startIndex   = Math.floor(scrollTop / ITEM_HEIGHT);
  const visibleCount = Math.ceil(containerHeight / ITEM_HEIGHT);
  const endIndex     = startIndex + visibleCount;
  return { startIndex, endIndex };
}

Step 4 — Render only the visible slice
Loop from startIndex to endIndex only — not across all 50,000 items.

Step 5 — Absolute positioning (the other non-obvious one)
If row #20,000 is the first one you render, the browser puts it at the top of the container by default. Wrong. Fix: top: index × ITEM_HEIGHT. Every row positions itself exactly where it would be if everything above it were rendered.

row.style.position = 'absolute';
row.style.top      = (i * ITEM_HEIGHT) + 'px';

Step 6 — Re-render on scroll
One scroll listener wrapped in requestAnimationFrame. Recalculate, re-render.

Step 7 — Overscan
Render 3 extra rows above and below the visible area as a buffer. Fast scrolls won't outrun your rendering.

const OVERSCAN = 3;

const startIndex = Math.floor(scrollTop / ITEM_HEIGHT) - OVERSCAN;
const endIndex   = startIndex + visibleCount + OVERSCAN * 2;

When to use a library instead

The technique above is what every virtualization library builds on. But for production apps, you'll likely want:

TanStack Virtual — framework-agnostic, handles variable heights, grids, horizontal lists. Best default in 2026.
react-window — lightweight, React-only, FixedSizeList maps directly to what we built here.
react-virtuoso — auto-measured heights, most "batteries included" option.

Build from scratch when you need zero dependencies, full rendering control, or want to understand what the library is doing under the hood.

When you don't need this

Under 100 items → just render normally
100–500 items → consider pagination first
500+ items with continuous scroll → virtualization is the right tool
Chat history, logs, activity feeds → classic use case, always virtualize

The full guide on onlyWebPro has a live 100,000-row demo you can scroll while inspecting the DOM in DevTools — the node count stays at ~18 no matter how far you scroll.

👉 Read the full guide + live demo

What's your go-to approach for large lists — roll your own or reach for a library?

AI-Driven Workflows for Frontend Developers — The Practical 2026 Guide

YT Low — Sun, 30 Aug 2026 00:49:30 +0000

Most "AI workflow" posts are either pure hype or pure dismissal. This one is neither.

I wrote a practical guide covering the exact workflow I use — which tool for which job, 5 copy-paste prompt templates, and what AI gets dangerously wrong. Here's the short version.

The tool split

No single tool wins everything. Here's how the work gets divided in 2026:

GitHub Copilot — daily inline completions
Cursor — React/Next.js daily driver, Agent mode for multi-file work
Claude Code — large refactors, complex bugs, security audits
Vercel v0 — UI scaffolding from a prompt or design spec

The most productive developers combine them rather than committing to one.

The 5-stage workflow

Stage	What you do	Best tool
🎨 Component generation	Scaffold from a full spec prompt	v0 → Cursor
🐛 Debugging	Ask for root cause before a fix	Cursor / Claude Code
🧪 Test generation	Generate + mutation-test every suite	Cursor / Copilot
♿ Accessibility audit	WCAG 2.2 AA against specific criteria	Any, with the right prompt
🔍 Code review	Senior engineer framing, not a checklist	Claude Code / Cursor

The one thing most posts don't say

AI-generated fetch logic routinely omits CSRF headers and input sanitisation. Any code touching auth, forms, or API calls needs a manual human review before it ships. No exceptions.

What's in the full guide

Complete prompt templates for all 5 stages (copy-paste ready)
The "AI handles well vs AI gets wrong" breakdown
Ground rules before you connect AI to a real codebase
The tool comparison table with specific task recommendations

👉 Read the full guide on onlyWebPro

Which AI tools are you actually using in your frontend workflow? Drop it in the comments.

I Built a Malaysian Cultural RPG in a Single HTML File — Here's What Broke

YT Low — Thu, 13 Aug 2026 06:05:10 +0000

This is a cross-post. Original article on onlyWebPro.

Budak Kampung is a browser-based, top-down RPG set across a 1440×1440 world map with Malay, Chinese, and Indian cultural zones — built entirely in one self-contained HTML file. No engine, no npm, no build step.

This is the honest devlog: every decision I made, and every bug that nearly broke it.

Why build this at all

I'd already built AstroHop — a vertical space platformer — as a single-file HTML game, mostly as a challenge. That worked out well enough that I wanted to push further, this time with something culturally personal: a top-down RPG set in Malaysia.

The single-file constraint matters to me. It means the game is genuinely portable — drag it to your desktop, email it, open it in any browser on any device. No CDN dependencies that disappear, no broken npm installs. Just one file.

The concept: a One Malaysia RPG in the browser

Malaysia is unusually rich material for an RPG world because the culture is genuinely multicultural — Malay, Chinese, and Indian communities each with distinct food, architecture, festivals, and traditions. A game that leans into that rather than a generic fantasy setting felt worth making.

The scope: a top-down 2D RPG with a single continuous world, three cultural zones, enterable buildings, NPC dialogue, a persistent save system, and mobile-first controls. All in one HTML file.

Feature	Details
🗺️ 1440×1440 World	One continuous map, no loading screens
🏘️ 3 Cultural Zones	Kampung Melayu, Pekan Cina, Little India
🚪 Enterable Buildings	Kopitiam, surau, kovil — each with their own interior
💾 localStorage Save	Position, visited buildings, dialogue flags
📱 Mobile-First	Zone-based d-pad, HUD that doesn't eat your taps
🎨 Vector NPCs	Hand-drawn canvas paths, no emoji, no sprites

Designing the world map

The world is 1440×1440 pixels of logical canvas space. Large enough to feel explorable, small enough to hand-code coordinates. The camera follows the player and clamps to world edges — only tiles within the camera view rectangle are drawn each frame. Basic culling, necessary from day one.

function updateCamera() {
  cam.x = player.x - canvas.width  / 2;
  cam.y = player.y - canvas.height / 2;

  // Clamp so camera never goes outside world bounds
  cam.x = Math.max(0, Math.min(cam.x, WORLD_W - canvas.width));
  cam.y = Math.max(0, Math.min(cam.y, WORLD_H - canvas.height));
}

I got this wrong early: I used CSS canvas dimensions instead of actual pixel dimensions, which caused the camera to drift on HiDPI displays. That fed directly into Bug #1.

Bug #1 — The blurry canvas (HiDPI hell)

Symptom: Sharp on a 1080p monitor, visibly blurry on any Retina display or modern phone. Tap coordinates were also wrong — tapping a door triggered an interaction zone two tiles away.

The browser has two separate size systems for a canvas: the CSS display size and the actual drawing buffer size. On a Retina display, devicePixelRatio is 2, meaning one CSS pixel maps to a 2×2 block of real screen pixels. Draw at CSS size without accounting for this and the browser upscales — blurry.

function setupCanvas() {
  const dpr = window.devicePixelRatio || 1;

  const cssW = window.innerWidth;
  const cssH = window.innerHeight;

  // Drawing buffer — scaled up by dpr
  canvas.width  = cssW * dpr;
  canvas.height = cssH * dpr;

  // Visual CSS size stays the same
  canvas.style.width  = cssW + 'px';
  canvas.style.height = cssH + 'px';

  // Scale context so all draw calls use CSS pixel coordinates
  ctx.scale(dpr, dpr);

  viewport.w = cssW;
  viewport.h = cssH;
}

⚠️ Critical: After ctx.scale(dpr, dpr), use CSS pixel coordinates everywhere — player position, collision, tap detection. Mix raw pixels and CSS pixels anywhere in the game loop and your collision zones go wrong.

Bug #2 — Emoji rendering killed the game

Symptom: Windows showed monochrome glyphs. Some Android phones showed boxes. iOS showed the right size but misaligned. 🌴 and 🏮 looked wildly different across Chrome Mac, Firefox Windows, and Safari iPhone.

I'd been drawing NPCs with ctx.fillText() emoji. A Malay grandma is just 👵, right? The problem: emoji rendering in canvas is completely platform-dependent. The browser uses the OS emoji font. Every OS has a different one — different size, baseline, colour rendering, fallback behaviour. No way to normalize this across platforms.

The fix was throwing out every emoji and drawing vector characters with canvas paths instead.

function drawCharacter(ctx, x, y, opts = {}) {
  const {
    skinTone = '#c68642',
    shirtColor = '#3ecfff',
    pantColor = '#2d3a5e',
    accessory = null,   // 'songkok' | 'kebaya-headscarf' | 'bindi'
    scale = 1
  } = opts;

  ctx.save();
  ctx.translate(x, y);
  ctx.scale(scale, scale);

  // Legs
  ctx.fillStyle = pantColor;
  ctx.fillRect(-7, -20, 6, 20);
  ctx.fillRect(1, -20, 6, 20);

  // Body
  ctx.fillStyle = shirtColor;
  ctx.fillRect(-9, -40, 18, 22);

  // Head
  ctx.fillStyle = skinTone;
  ctx.beginPath();
  ctx.arc(0, -52, 12, 0, Math.PI * 2);
  ctx.fill();

  if (accessory === 'songkok') drawSongkok(ctx);
  if (accessory === 'bindi')   drawBindi(ctx);

  ctx.restore();
}

function drawSongkok(ctx) {
  ctx.fillStyle = '#1a1a2e';
  ctx.fillRect(-13, -67, 26, 8);  // brim
  ctx.fillRect(-10, -78, 20, 12); // crown
}

More work, but the upside is real: characters look identical on every device, you control every pixel, and adding a new cultural accessory is a few canvas draw calls — not a new sprite sheet.

NPC dialogue and enterable buildings

Each NPC has an id, a position, and an array of dialogue strings. Within interaction range + action button → dialogue state flag flips → box renders over the canvas. Simple.

Buildings were more interesting. An enterable building is a zone rectangle in world space. Walk into it → switch to an interior scene with its own tilemap, furniture, and NPCs. Interiors render exactly the same way as the world — just a different data set.

const BUILDINGS = [
  {
    id: 'kopitiam',
    label: 'Old Town Kopitiam',
    worldZone: { x: 820, y: 340, w: 48, h: 12 },
    entryPos:  { x: 200, y: 320 },
    exitPos:   { x: 820, y: 360 },
    scene: 'interior-kopitiam'
  },
];

function checkBuildingEntry() {
  for (const b of BUILDINGS) {
    if (overlaps(player, b.worldZone)) {
      activeScene     = b.scene;
      player.x        = b.entryPos.x;
      player.y        = b.entryPos.y;
      currentBuilding = b;
      return;
    }
  }
}

The save system with localStorage

Small state object serialised to localStorage. Player position, active scene, visited building IDs, completed dialogue flags. On load, restore or start fresh.

const SAVE_KEY = 'budakkampung_save';

function saveGame() {
  const state = {
    playerX: player.x,
    playerY: player.y,
    scene:   activeScene,
    visitedBuildings:  [...visitedBuildings],
    completedDialogue: [...completedDialogue],
    savedAt: Date.now()
  };
  localStorage.setItem(SAVE_KEY, JSON.stringify(state));
}

function loadGame() {
  const raw = localStorage.getItem(SAVE_KEY);
  if (!raw) return false;

  try {
    const s = JSON.parse(raw);
    player.x          = s.playerX;
    player.y          = s.playerY;
    activeScene       = s.scene;
    visitedBuildings  = new Set(s.visitedBuildings);
    completedDialogue = new Set(s.completedDialogue);
    return true;
  } catch (e) {
    localStorage.removeItem(SAVE_KEY);
    return false;
  }
}

The try/catch around JSON.parse() is not optional. localStorage can return corrupted data — full storage, manual edits, format changes between game versions. Crashing on load is unforgivable. Silently starting a new game is always the right fallback.

Bug #3 — The player got permanently stuck

Symptom: Player saves inside a building, quits, reloads. Correct interior position restored — but the exit door does nothing. The only escape: delete the save.

Root cause: one function handled both entering and exiting buildings. Exit detection checked against world-space entry zones — meaningless inside an interior.

Fix: split into two functions, each only called in the right scene context.

const INTERIOR_EXITS = {
  'interior-kopitiam': { x: 180, y: 360, w: 60, h: 20 },
};

function gameTick() {
  if (activeScene === 'world') {
    checkBuildingEntry();
  } else {
    checkBuildingExit();
  }
}

function checkBuildingExit() {
  const exitZone = INTERIOR_EXITS[activeScene];
  if (!exitZone) return;

  if (overlaps(player, exitZone)) {
    player.x        = currentBuilding.exitPos.x;
    player.y        = currentBuilding.exitPos.y;
    activeScene     = 'world';
    currentBuilding = null;
  }
}

Bug #4 — The HUD was eating all my clicks

Symptom: Save button works fine. Tapping the lower game world does nothing — even though the HUD buttons aren't visually there. The game feels broken in the bottom third.

The HUD is an absolutely-positioned <div> over the canvas. It spans full screen height, but the buttons only sit in the corners. The transparent container was intercepting all pointer events in its area.

#hud {
  position: absolute;
  inset: 0;
  z-index: 10;
  pointer-events: none; /* container is click-through */
}

/* Re-enable only on actual interactive children */
#hud button,
#hud .dpad-zone {
  pointer-events: auto;
}

pointer-events: none on the container, auto on the children. One-liner fix for a genuinely confusing bug — the element isn't visually blocking anything, it's just intercepting pointer events invisibly.

What I learned

Problem	Lesson
HiDPI blurriness	Multiply canvas buffer by `devicePixelRatio` first, before any draw calls
Emoji inconsistency	Never use `ctx.fillText()` with emoji. Draw with canvas paths
Player stuck	Scene-aware functions. Entry logic only in world scene. Exit logic only in interior scene
HUD eating taps	`pointer-events: none` on the container, `auto` on children
Save corruption	Always wrap `JSON.parse()` in try/catch. Fail gracefully to a new game
Building transitions	Separate entry and exit into clearly named functions. Don't unify what has different conditions

The single-file constraint forced me to fight for every feature. No build step, no module system, no "I'll just add a dependency." Everything has to justify its weight. That pressure produces surprisingly clean code.

The game works. It plays identically on every device. It has zero dependencies. For a side project that started as "can I build an RPG in pure HTML?" — that feels like success.

Originally published at onlyWebPro