DEV Community: YT Low

Web Workers — Stop Freezing the UI With This Practical Guide

YT Low — Sat, 10 Oct 2026 10:12:46 +0000

Full guide with a live frozen vs smooth UI demo, Comlink setup, transferable objects, and React hook on
onlyWebPro.

JavaScript on the main thread shares one thread with rendering, event handling, and layout. A heavy computation — sorting 200k rows, parsing a 10MB CSV — blocks everything until it finishes. The UI freezes.

Web Workers move that computation to a separate OS thread. The main thread stays completely free.

Why async/await doesn't solve this

Promises and async/await are still single-threaded. They let you defer work so other tasks can run in between — but if the computation itself is CPU-bound, the thread is still blocked while it runs. Web Workers are a separate thread. That's a completely different thing.

The basic pattern

// worker.js — runs in its own thread
self.onmessage = function(event) {
  const { n } = event.data;
  const result = findNthPrime(n);   // heavy computation here
  self.postMessage({ result });
};

// main.js — creates and communicates with the worker
const worker = new Worker('worker.js');
worker.onmessage = ({ data }) => console.log(data.result);
worker.postMessage({ n: 8000 });

Comlink — the right way in 2026

Raw postMessage gets messy fast: manual message routing, matching requests to responses, propagating errors. Comlink (1.1kB, Google) wraps all of that and lets you call worker functions as regular async functions.

// heavy.worker.js
import * as Comlink from 'comlink';

Comlink.expose({
  async findNthPrime(n) { /* ... */ },
  async sortLargeArray(arr) { return [...arr].sort((a, b) => a - b); },
  async parseCSV(text) { return text.trim().split('\n').map(r => r.split(',')); }
});

// main.js
import * as Comlink from 'comlink';
const worker = new Worker(new URL('./heavy.worker.js', import.meta.url), { type: 'module' });
const api = Comlink.wrap(worker);

// Feels like a local async call — no postMessage in sight
const prime  = await api.findNthPrime(8000);
const sorted = await api.sortLargeArray(hugeArray);

Transferable objects — zero-copy data transfer

By default, postMessage deep-copies data. For a 50MB ArrayBuffer that's ~180ms of copy time — defeating the purpose of the worker. Transferable objects transfer ownership in ~0.1ms regardless of size.

const buffer = new ArrayBuffer(50 * 1024 * 1024); // 50 MB

// ❌ Copy — ~180ms for 50MB
worker.postMessage({ buffer });

// ✅ Transfer — ~0.1ms, buffer unusable on main thread afterward
worker.postMessage({ buffer }, [buffer]);

Use transfer for: ArrayBuffer, ImageBitmap, OffscreenCanvas, streams.

React hook — clean lifecycle management

export function useWorker(workerUrl) {
  const workerRef = useRef(null);
  const apiRef    = useRef(null);

  useEffect(() => {
    workerRef.current = new Worker(workerUrl, { type: 'module' });
    apiRef.current    = Comlink.wrap(workerRef.current);
    return () => workerRef.current?.terminate(); // always clean up
  }, []);

  return apiRef;
}

When to use a worker (and when not to)

✅ Use for: sorting/filtering 100k+ rows, parsing large files, image processing, running a search index, encryption/hashing

❌ Don't use for: fetch calls (already async), DOM updates (workers have no DOM access), computations under ~5ms (message overhead isn't worth it)

The full guide has a live demo where you can see a bouncing animation freeze on the main thread and keep running with a worker — same computation, completely different experience.

👉 Read the full guide + live demo

Part 4 — the final post — of the Frontend Performance Series on onlyWebPro.

Have you shipped Web Workers in a production app? What was the use case?

Debounce vs Throttle — The Visual Guide Every Frontend Developer Needs

YT Low — Sat, 10 Oct 2026 10:11:29 +0000

Full guide with an interactive side-by-side demo, React hooks, and a complete decision table on
onlyWebPro.

The one-line difference:

Debounce — "wait until they've stopped, then act once"
Throttle — "act on a fixed schedule, no matter what"

Pick the wrong one and your UI either feels broken (debounce on scroll progress) or fires too many API calls (throttle on search input).

Debounce — built from scratch

Every call resets the timer. The function only runs once the events have been quiet for the full delay.

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

// Only calls the API after 300ms of typing silence
const handleSearch = debounce((query) => fetchResults(query), 300);
searchInput.addEventListener('input', (e) => handleSearch(e.target.value));

Throttle — built from scratch

Checks elapsed time and skips calls that arrive too soon.

function throttle(fn, interval) {
  let lastTime = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn.apply(this, args);
    }
  };
}

// Updates scroll progress at most every 100ms
const updateProgress = throttle(() => {
  const pct = window.scrollY / (document.body.scrollHeight - window.innerHeight);
  progressBar.style.width = (pct * 100) + '%';
}, 100);

window.addEventListener('scroll', updateProgress, { passive: true });

Always add passive: true to scroll listeners that don't call preventDefault() — it's a free performance win.

The critical difference in output behaviour

	Debounce	Throttle
Output while events are active	Zero — silent	Regular — fires on schedule
Output after events stop	One final call	Nothing
Best for	Search, validation, auto-save	Scroll tracking, progress bars, analytics

This is why debounce is wrong for scroll-linked UI — it shows nothing while the user is actively scrolling.

When to use requestAnimationFrame instead

For anything directly changing visual properties (transform, opacity, parallax), skip throttle entirely. Use requestAnimationFrame — it syncs with the browser's actual paint cycle for smoother results.

let ticking = false;
window.addEventListener('scroll', () => {
  if (ticking) return;
  requestAnimationFrame(() => {
    el.style.transform = `translateY(${window.scrollY * 0.5}px)`;
    ticking = false;
  });
  ticking = true;
}, { passive: true });

The three-way decision

Debounce → search inputs, form validation, auto-save, resize recalculation
Throttle → scroll progress, analytics, infinite scroll triggers, API rate-limiting
requestAnimationFrame → parallax, sticky header opacity, canvas animations

The full guide has a live interactive demo where you can click rapidly and watch raw events, debounced output, and throttled output on separate timelines — the clearest way to see how differently they behave.

👉 Read the full guide + interactive demo

Part 3 of the Frontend Performance Series on onlyWebPro.

Which do you reach for more often — debounce or throttle? And has rAF replaced throttle for you on scroll animations?

Lazy Loading Images in 2026 — When Native Is Enough and When It Isn't

YT Low — Sat, 10 Oct 2026 10:08:40 +0000

Full guide with live demos, blur-up placeholder code, and a complete decision table on
onlyWebPro.

One HTML attribute defers every offscreen image — no JavaScript, no library, ~95% browser coverage in 2026.

<img src="product.jpg" alt="Product" width="800" height="600" loading="lazy">

But native lazy loading has real limitations. Here's when it's enough, and when you need Intersection Observer.

The LCP mistake that kills Core Web Vitals

This is the most common lazy loading error — never add loading="lazy" to your LCP image.

The LCP (Largest Contentful Paint) element — usually the hero image — gets delayed by 200–500ms when lazy-loaded. Lighthouse flags it directly.

<!-- ❌ Wrong — delays the hero image -->
<img src="hero.jpg" alt="Hero" loading="lazy">

<!-- ✅ Right — prioritise it instead -->
<img src="hero.jpg" alt="Hero" fetchpriority="high">

Rule: any image visible in the first ~800px without scrolling should never be lazy-loaded.

Browser support in 2026

Browser	`loading="lazy"`
Chrome 77+ / Edge 79+	✓
Firefox 75+	✓
Safari 15.4+	✓
Global coverage	~95%

Unsupported browsers silently ignore the attribute — images load normally. No polyfill needed.

What native lazy loading cannot do

Custom placeholders (blur-up, skeleton, dominant colour)
Fade-in animations on image arrival
CSS background-image properties
Custom load threshold (distance before viewport)

For all of these, use Intersection Observer.

Intersection Observer — when you need more control

const observer = new IntersectionObserver((entries) => {
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;
    const img = entry.target;
    img.src = img.dataset.src;           // swap data-src into src
    img.addEventListener('load', () => img.classList.add('loaded'));
    observer.unobserve(img);             // stop watching once loaded
  }
}, { rootMargin: '300px 0px' });        // start loading 300px early

document.querySelectorAll('img.lazy[data-src]')
  .forEach(img => observer.observe(img));

The rootMargin: '300px 0px' gives the browser a head start — images are fully loaded before the user scrolls to them.

The quick decision table

Situation	Use
Standard below-fold `<img>`	`loading="lazy"`
Hero / LCP image	`fetchpriority="high"`
Fade-in on load	Intersection Observer
Blur-up placeholder	Intersection Observer
CSS `background-image`	Intersection Observer
`<iframe>` (YouTube, Maps)	`loading="lazy"`

The full guide has live demos for both techniques, the complete blur-up placeholder pattern, and the CSS background-image solution.

👉 Read the full guide

Part 2 of the Frontend Performance Series on onlyWebPro.

Do you still reach for Intersection Observer or does native cover everything you need these days?

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