DEV Community: Nidal tahir

How I Built a Secure, Scalable Auth System in Next.js 15 (with JWT, Edge Middleware, and Drizzle)

Nidal tahir — Mon, 26 May 2025 07:00:00 +0000

Authentication is the backbone of most modern web applications, yet it's often one of the most challenging aspects to implement securely. With Next.js 15's new features and improved App Router, building a robust authentication system has become more streamlined than ever.

In this guide, I'll walk you through creating a production-ready authentication system that balances security, performance, and developer experience. We'll cover everything from JWT implementation to edge middleware optimization.

👉 Full source code available on GitHub: auth-next-my-app

Why This Architecture?

Before diving into code, let's understand the key decisions behind this implementation:

JWT over Server Sessions: While server sessions are excellent for traditional applications, JWTs offer stateless authentication that scales horizontally without session stores. Perfect for modern serverless deployments.

HTTP-only Cookies: Unlike localStorage, HTTP-only cookies are immune to XSS attacks. They're automatically included in requests and can't be accessed by malicious scripts.

Edge Middleware: Next.js 15's middleware runs at the edge, meaning authentication checks happen before your application code even loads—resulting in faster redirects and better UX.

Authentication Flow Overview

Here's how our secure authentication system works:

User Request → Edge Middleware → JWT Verification → Protected Route
     ↓              ↓               ↓                    ↓
Sign In/Up → HTTP-Only Cookie → Token Validation → Dashboard Access
     ↓              ↓               ↓                    ↓
  Database ← Password Hash ← bcrypt Verification ← Authorized User

Flow breakdown:

User authentication → Credentials verified against database
JWT generation → Secure token created with 24h expiration
HTTP-only cookie → Token stored safely, immune to XSS
Edge middleware → Lightning-fast route protection
Protected access → Seamless user experience

The Tech Stack

Our authentication system leverages:

Next.js 15.1.8 with App Router
TypeScript for type safety
JWT (jose) for token management - If you're not familiar with jose, it's a zero-dependency library for working with JWTs—lightweight and perfect for edge runtimes
bcryptjs for password hashing
Drizzle ORM with SQLite - Drizzle is a type-safe ORM that generates SQL queries at build time, offering better performance than traditional ORMs
Zod for validation - Zod provides runtime type checking and validation, ensuring your API receives exactly the data it expects
Tailwind CSS + Radix UI for components

Core Authentication Flow

1. User Registration

The registration process implements several security layers:

// Simplified registration flow
async function registerUser(data: RegisterData) {
  // 1. Validate input with Zod
  const validated = registerSchema.parse(data);

  // 2. Hash password with bcrypt (10 rounds)
  const hashedPassword = await bcrypt.hash(validated.password, 10);

  // 3. Save user to database
  const user = await db.insert(users).values({
    email: validated.email,
    password: hashedPassword,
    name: validated.name
  });

  // 4. Generate JWT token
  const token = await new SignJWT({ userId: user.id })
    .setProtectedHeader({ alg: 'HS256' })
    .setExpirationTime('24h')
    .sign(secret);

  // 5. Set HTTP-only cookie
  cookies().set('token', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
    maxAge: 86400 // 24 hours
  });
}

Security highlights:

10 rounds of bcrypt: Provides strong protection against rainbow table attacks
24-hour token expiration: Limits exposure window if tokens are compromised
Strict SameSite policy: Prevents CSRF attacks

2. Route Protection with Middleware

Next.js 15's middleware runs at the edge, making it incredibly fast:

// middleware.ts
export async function middleware(request: NextRequest) {
  // Protected routes
  if (request.nextUrl.pathname.startsWith('/dashboard')) {
    const token = request.cookies.get('token')?.value;

    if (!token) {
      return NextResponse.redirect(new URL('/sign-in', request.url));
    }

    try {
      // Verify JWT at the edge
      await jwtVerify(token, secret);
    } catch {
      return NextResponse.redirect(new URL('/sign-in', request.url));
    }
  }

  return NextResponse.next();
}

Performance benefits:

Edge computing: Authentication checks happen closest to users
No server round-trips: Redirects happen before hitting your application
Reduced latency: Faster than traditional server-side checks

3. API Route Implementation

The API routes use Next.js 15's improved App Router structure:

// app/api/auth/login/route.ts
export async function POST(request: Request) {
  try {
    const { email, password } = await request.json();

    // Find user in database
    const user = await db.select().from(users)
      .where(eq(users.email, email))
      .limit(1);

    if (!user.length) {
      return NextResponse.json(
        { error: 'Invalid credentials' }, 
        { status: 401 }
      );
    }

    // Verify password
    const validPassword = await bcrypt.compare(password, user[0].password);

    if (!validPassword) {
      return NextResponse.json(
        { error: 'Invalid credentials' }, 
        { status: 401 }
      );
    }

    // Generate and set token...

  } catch (error) {
    return NextResponse.json(
      { error: 'Something went wrong' }, 
      { status: 500 }
    );
  }
}

Database Design & ORM Choice

Why Drizzle ORM?

Drizzle offers several advantages over alternatives:

Type-safe queries: Full TypeScript support with auto-completion
Zero runtime overhead: Queries are as fast as raw SQL
Edge-compatible: Works perfectly with serverless functions
Simple migrations: Easy schema evolution

// Schema definition
export const users = sqliteTable('users', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  email: text('email').notNull().unique(),
  password: text('password').notNull(),
  name: text('name').notNull(),
  createdAt: integer('created_at', { mode: 'timestamp' })
    .default(sql`CURRENT_TIMESTAMP`)
});

SQLite vs PostgreSQL

Development: SQLite provides zero-config setup—perfect for getting started quickly.

Production: The system seamlessly transitions to PostgreSQL on platforms like Vercel, where serverless functions require managed databases.

Security Best Practices Implemented

1. Password Security

bcrypt with 10 rounds: Industry standard for password hashing
No password storage: Original passwords never touch the database

2. Token Security

Short expiration: 24-hour tokens limit breach impact
HTTP-only cookies: Prevents XSS token theft
Secure flags: HTTPS-only in production

3. Input Validation

Zod schemas: Runtime type checking prevents injection attacks
Server-side validation: Never trust client data

4. Error Handling

Generic error messages: Prevents user enumeration attacks
Proper status codes: Clear API responses without revealing system details

Performance Optimizations

1. Edge Middleware

Authentication checks happen at CDN edge locations, reducing latency by up to 50% compared to server-side checks.

2. Efficient Database Queries

// Optimized user lookup
const user = await db.select({
  id: users.id,
  email: users.email,
  password: users.password
}).from(users)
.where(eq(users.email, email))
.limit(1); // Always limit queries

3. Database Strategy: SQLite vs PostgreSQL

For Development & Small Apps:

SQLite + Drizzle provides zero-config setup and excellent performance
Perfect for MVPs, personal projects, and teams getting started quickly
File-based database means no external dependencies

For Production & Scale:

PostgreSQL + Drizzle offers better concurrency and advanced features
Essential for multi-tenant applications or high-traffic scenarios
Serverless platforms (Vercel, Netlify) require managed databases anyway

Migration tip: Drizzle makes switching between databases seamless—same ORM, different connection string.

4. Component Optimization

UI components use React Server Components where possible, reducing client-side JavaScript bundle size.

Deployment Considerations

Local Development

# Quick setup
git clone https://github.com/nidal1111/auth-next-my-app.git
cd auth-next-my-app
npm install
cp .env.local.example .env.local
# Add your JWT_SECRET
npm run db:push
npm run dev

Production Deployment

The system includes production configurations for:

Vercel: Automatic PostgreSQL integration
Traditional servers: PM2 configurations included
Docker: Multi-stage builds for optimal performance

Testing Your Implementation

The repository includes comprehensive testing scenarios:

Registration flow: Create new accounts
Login validation: Test credential verification
Route protection: Verify middleware functionality
Session management: Test token expiration
Security headers: Validate cookie settings

What's Next?

This implementation provides a solid foundation, but consider these enhancements:

OAuth integration (Google, GitHub)
Two-factor authentication
Password reset functionality
Rate limiting for login attempts
Session management dashboard

Get the Complete Code

The full implementation is available on GitHub: auth-next-my-app

Use it as:

🚀 Starter template for your next project
📚 Learning resource for authentication patterns
🔧 Reference implementation for security best practices

Contributing

Found a bug or have an improvement idea? The repository welcomes contributions! Whether it's:

Security enhancements
Performance optimizations
Documentation improvements
New feature implementations

Open a Pull Request and help make this authentication system even better for the community.

Building secure authentication doesn't have to be overwhelming. With the right architecture and tools, you can create a system that's both secure and maintainable. This implementation demonstrates that production-ready authentication is achievable with modern Next.js patterns.

What authentication challenge are you facing in your current project? Share in the comments below!

Lean Thinking in Engineering Development: Maximizing Value, Minimizing Waste

Nidal tahir — Sun, 18 May 2025 16:30:38 +0000

TL;DR: Apply Toyota's lean principles to engineering by focusing on customer value, eliminating waste, limiting work in progress, using pull systems, and continuously improving. AI is now helping teams make these practices even more effective.

Introduction

Engineering teams everywhere need to deliver faster while using resources wisely. Lean thinking—which started at Toyota for car manufacturing—works surprisingly well for software teams too. This article shows how these ideas can help your team build better products with less frustration.

Core Principles of Lean in Engineering Context

1. Identify Value from the Customer's Perspective

Before writing any code, ask "Who needs this and why?"

Connect features to actual user problems
Choose what to build based on user value, not just what's technically interesting
Check your assumptions by talking to real users

I've seen teams spend months building features nobody wanted. Don't make this mistake.

2. Spot and Remove Waste

In everyday engineering work, waste shows up as:

┌─────────────────┬────────────────────────────┐
│ TYPE OF WASTE   │ HOW IT LOOKS IN CODING     │
├─────────────────┼────────────────────────────┤
│ Defects         │ Bugs that need fixes       │
│ Overproduction  │ Features built too early   │
│ Waiting         │ Delayed approvals          │
│ Unused talent   │ Skills not fully used      │
│ Transportation  │ Work bouncing between teams│
│ Inventory       │ Half-finished code         │
│ Motion          │ Constant context switching │
│ Extra processing│ Overengineered solutions   │
└─────────────────┴────────────────────────────┘

Take a few minutes each week to ask: "What slowed us down?" That's your waste.

3. Create Flow by Limiting Work-in-Progress

Here's a truth that feels wrong: doing less at once means finishing more overall.

Try these steps:

Set a cap on how many tasks your team works on at once
Break big features into smaller pieces
Use a simple board to see where work is piling up
Fix the bottlenecks that slow work down

Visual example: A team board with WIP limits might look like this:

┌─────────────┬───────────────┬─────────────┬────────────┐
│ BACKLOG     │ IN PROGRESS   │ REVIEW      │ DONE       │
│             │ (max 3)       │ (max 2)     │            │
├─────────────┼───────────────┼─────────────┼────────────┤
│ Feature A   │ Feature C     │ Feature B   │ Feature X  │
│ Feature D   │ Bug Fix #42   │             │ Feature Y  │
│ Feature E   │               │             │ Bug Fix #37│
│ Bug Fix #55 │               │             │            │
└─────────────┴───────────────┴─────────────┴────────────┘

Teams who do this ship more predictably and with fewer emergencies.

4. Use Pull Systems

Most teams push work forward regardless of what's happening downstream. Smart teams do the opposite:

Only start new work when there's capacity to handle it
Focus on finishing tasks rather than starting new ones
Release when ready, not on random dates

This creates a smoother, steadier pace that feels less chaotic.

5. Keep Improving (Kaizen)

Make getting better a habit:

End each week by asking "What could work better?"
Try small changes and see what happens
Measure what matters to your team
Share what you learn

AI: The New Boost for Lean Engineering

AI is changing how teams apply lean thinking:

AI can spot patterns in your work that show where time is being wasted
It helps predict which tasks might cause delays before they happen
AI tools can generate and test options much faster than manual processes
Smart assistants reduce the busy work that slows down your best people

  Traditional Approach       With AI Assistance
  ┌─────────────────┐       ┌─────────────────┐
  │ Manual waste    │       │ Automated waste │
  │ identification  │──────▶│ detection       │
  └─────────────────┘       └─────────────────┘
         │                          │
         ▼                          ▼
  ┌─────────────────┐       ┌─────────────────┐
  │ Human judgment  │       │ AI-enhanced     │
  │ for planning    │──────▶│ prediction      │
  └─────────────────┘       └─────────────────┘
         │                          │
         ▼                          ▼
  ┌─────────────────┐       ┌─────────────────┐
  │ Manual testing  │       │ Rapid AI-powered│
  │ of solutions    │──────▶│ simulation      │
  └─────────────────┘       └─────────────────┘

The result? Teams using AI with lean practices are finding better solutions faster.

Quick-Start Implementation

Pick ONE thing to try this week:

15-min waste hunt: Find just one thing that feels wasteful and fix it
Visual workflow: Put your team's work on a simple board so everyone can see it
WIP check: Count how many tasks your team is working on right now - is it too many?

Conclusion

Lean thinking helps teams focus energy on what really matters—solving customer problems without wasting effort. When you add AI tools to the mix, these benefits multiply.

Teams using these ideas deliver faster and build products people actually want to use. Start small, measure results, and adjust as you learn.

Using Physics to Create Realistic 3D Effects in the Browser

Nidal tahir — Thu, 03 Apr 2025 09:30:00 +0000

👉 View the live demo on CodePen

Ever wondered how those mesmerizing 3D animations work without heavy libraries? Turns out, the secret is hiding in plain sight—it's physics! I recently built a particle system that feels genuinely three-dimensional using just vanilla JavaScript and Canvas. Let me show you how physics transforms flat pixels into an immersive experience.

Why Physics Matters in 3D

Our brains are hardwired to understand physical motion. When digital objects behave according to the laws we intuitively know, they instantly feel more real. It's not about perfect graphics—it's about movement that makes sense to our brains.

Step 1: Creating Depth Perception

The foundation of any 3D effect is perspective projection—making distant objects appear smaller. In nature, this happens because of how light travels through space. We mimic this with a simple but powerful formula:

scale = focalLength / (focalLength + z);
projectedX = x * scale + (screenWidth / 2);
projectedY = y * scale + (screenHeight / 2);

This z-division is what gives our flat screen the illusion of depth. Objects closer to the viewer (smaller z values) appear larger than distant ones—just like in real life. Just like when you look down a hallway—walls seem to converge in the distance. That's perspective projection in action. The focal length controls the perceived field of view—smaller values exaggerate depth, while larger ones flatten it.

Step 2: Adding Forces

Static objects are boring. Real things move, accelerate, and respond to forces. In our particle system, I implemented:

Gravitational attraction: Particles are pulled toward a central point
Friction: Velocities gradually decrease, simulating air resistance
Elastic collisions: Particles bounce off boundaries while losing energy
Inverse square forces: We simulate a repulsive inverse-square force similar to electrostatic repulsion around the mouse. For simplicity, we treat all particles as unit-mass objects.

The key to realistic motion lies in how we update positions and velocities:

// Apply acceleration to velocity
this.vx += accelerationX;
this.vy += accelerationY;

// Apply friction
this.vx *= friction;
this.vy *= friction;

// Update position
this.x += this.vx;
this.y += this.vy;

Step 3: Natural Light Behavior

Light follows physical laws too. I used these principles to enhance realism:

Distance attenuation: Objects farther away appear dimmer
Radial gradients: Particles have soft edges that simulate light diffusion
Depth-based opacity: Atmospheric perspective makes distant objects fade

We mimic light attenuation and softness using simple radial gradients and distance-based opacity—not physically accurate, but perceptually effective. These visual approximations create convincing depth cues without the computational cost of real light simulation.

Step 4: Adding Organic Movement

Nothing in nature moves in perfect straight lines. Adding subtle oscillations creates more convincing motion:

this.x += Math.sin(time * 0.3) * 0.3;
this.y += Math.cos(time * 0.2) * 0.3;

These small perturbations mimic the tiny random forces that affect objects in the real world.

Step 5: Depth Sorting

In the real world, closer objects obscure farther ones. We achieve this by sorting particles by their z-position and drawing them back-to-front:

particles.sort((a, b) => b.z - a.z);

The Final Touch: Interactive Forces

Think of the mouse like a magnetic field—particles get "pushed" away as you approach. The coup de grâce is adding mouse interaction that follows the inverse square law—just like gravity and electromagnetic forces in the real world. Forces get exponentially stronger as you get closer:

const force = strength / Math.max(1, distance);

This creates a visceral feeling of pushing through a field of particles that responds naturally to your movements.

Why It Works

The magic isn't in fancy 3D engines—it's in physics. When digital objects follow the same rules as physical ones, our brains instantly recognize the patterns. The simulation becomes believable not because it looks photorealistic, but because it behaves realistically.

Next time you're crafting visual effects, remember that adding even simplified physics can transform flat graphics into immersive experiences. Our visual system evolved to understand a world governed by physical laws—tap into those expectations and watch your creations come alive!

Try waving your mouse through the particle field in the demo. Feel that? That's physics doing its magic! ✨

✨ Want to feel it in action?
👉 View the live demo on CodePen

How to Make Your NextJS App Painfully Slow 🐢💤

Nidal tahir — Wed, 02 Apr 2025 13:30:00 +0000

Ever dreamed of creating a NextJS app that's so sluggish it makes users question their life choices? Look no further! Follow this comprehensive guide to ensure your Next application performs like it's running on a potato connected to dial-up internet. Let's dive into the art of building spectacularly slow applications!

⚡ TL;DR:

Want your NextJS app to crawl? Skip image optimization, load your entire codebase upfront, trigger endless re-renders, ignore server components, deploy massive edge functions, and run calculations in all the wrong places. Or do the opposite if you actually want happy users.

1. Say No to Image Optimization

Next.js spent countless hours creating an Image component that automatically handles responsive sizing and lazy loading.

Why would you use that?

Instead, reach for the classic <img> tag. Nothing says "I respect traditions" like forcing mobile users to download your 4MB hero image at full resolution. Those layout shifts when images finally load add a charming element of surprise.

The client complaining about Core Web Vitals? Tell them it's a premium feature for phase two.

2. Load Everything Upfront Because YOLO

Code splitting? Dynamic imports? Lazy loading? Sounds like a lot of work.

Real developers import the entire codebase on page load. Admin dashboard? Load it on the homepage. Data visualization library? Everyone might need that eventually. All 15 form validation libraries you couldn't decide between? Better safe than sorry.

When users complain about the 8MB JavaScript bundle, remind them that patience is a virtue.

3. Treat Server Components Like They're Radioactive

Next.js 13+ introduced server components that reduce JavaScript sent to the client. Clearly, this is a trap.

Stick with client components for everything. Why let the server handle data fetching and rendering when you can push all that work to your users' devices?

Make sure to add "use client" at the top of every file, even for completely static UI elements. Consistency is key!

4. Build Edge Functions That Would Make AWS Blush

Serverless functions should be small, focused pieces of code with quick cold starts. That's for amateurs.

Instead, create massive edge functions that import half of npm. Nothing impresses like a function that takes 8 seconds to cold start because you included an entire machine learning library to validate email addresses.

When your functions hit timeout limits, just split them into two equally massive functions that call each other.

5. Re-render All The Things

React's component model is built around efficient updates. Ignore that completely.

Store all your state at the top level. Pass it down to every component. Update that global state on every keystroke. Watch your app re-render like a slideshow from 1998.

Never use React.memo, useMemo, or useCallback – those are just fancy decorations for people who don't appreciate the warm glow of their CPU fans.

6. Run Expensive Calculations in All the Wrong Places

Complex data transformations? Do them on the client during render. Simple formatting that could happen at build time? Make it a runtime calculation on every page load. Database queries that could be cached? Refetch that data on every request!

For bonus points, implement recursive functions without memoization in frequently rendered components. Nothing says "professional" like calculating the same Fibonacci sequence 50 times per second.

The Truth Behind the Joke

These anti-patterns show up in real NextJS apps more often than you'd think. Each "how to fail" point has a corresponding best practice:

Use next/image for optimization, lazy loading, and preventing layout shifts
Embrace code splitting with dynamic imports to load only what's needed
Leverage server components for data fetching and static elements
Keep edge functions lean and focused to minimize cold start times
Prevent unnecessary re-renders with proper state management
Calculate at the right time and place - build time for static data, server-side for cacheable data, and client-side only when necessary

The difference between a sluggish NextJS app and a lightning-fast one often comes down to these fundamentals. Your users won't thank you when things are fast, but they'll definitely notice when they're slow.

What performance sins have you witnessed in NextJS apps? Confess your frontend transgressions below!

Shout-out to @cypriantinasheaarons — your post inspired me to try a more sarcastic take on performance tips. Loved it!

🚨 5 Performance Debugging Tricks Every Web Dev Should Know (But Most Don't)

Nidal tahir — Tue, 01 Apr 2025 07:15:00 +0000

Ever watched your beautiful web app turn into a stuttering mess the moment actual users start hammering it? You're not alone. While everyone obsesses over fancy frameworks and pixel-perfect designs, performance debugging often gets treated like that weird relative nobody wants to talk about at family gatherings.

But what if you could catch performance issues before they escape into the wild? I've collected a handful of my favorite quick-and-dirty performance debugging techniques that have saved my bacon countless times. These aren't the fancy monitoring solutions your DevOps team wants you to use—these are the scrappy tricks for when you need answers now.

⚡ TL;DR:

Stop flying blind with performance issues. Use console.time() to measure specific operations, leverage Performance API for precision timing, use DevTools paint flashing to spot excessive repaints, learn how to count frames with requestAnimationFrame, and check memory leaks with heap snapshots. These five minutes of setup can save you hours of debugging.

1. `console.time()`

Everyone knows console.log() but have you been properly introduced to its cooler cousin? console.time() and console.timeEnd() let you measure precise operation durations with minimal effort:

console.time('dataProcessing');

// Imagine some complex data manipulation here
const result = massiveArray.map(x => complexTransformation(x))
  .filter(x => someCondition(x))
  .reduce((acc, val) => buildSomethingExpensive(acc, val), {});

console.timeEnd('dataProcessing'); // Outputs: dataProcessing: 1234.56ms

Why it's a game-changer: Label multiple timers to track different operations simultaneously, and they're perfect for measuring real user operations instead of synthetic benchmarks.

2. Performance API for Super-Precise Timing

When you need microsecond precision (or need to measure things in production without console), the Performance API is your friend:

// Mark the beginning of an operation
performance.mark('fetchStart');

await fetchDataFromServer();

// Mark the end
performance.mark('fetchEnd');

// Measure the difference
performance.measure('fetchTime', 'fetchStart', 'fetchEnd');

// Get and log all measurements
const fetchMeasure = performance.getEntriesByName('fetchTime')[0];
console.log(`Fetch took exactly ${fetchMeasure.duration.toFixed(2)}ms`);

// Clean up when you're done
performance.clearMarks();
performance.clearMeasures();

This approach can stay in production code because it doesn't log anything automatically. I've used this to identify why one particular API call was consistently slower for certain European customers (turned out to be a CDN routing issue).

3. Paint Flashing — See What's Actually Repainting

Not everyone knows Chrome DevTools has this magical feature that shows you exactly which parts of your page are being repainted:

Open Chrome DevTools (F12)
Press Esc to open the drawer
Click the ⋮ menu in the drawer and select "Rendering"
Check "Paint flashing"

Now watch your page turn into a green light district every time something repaints. It's eye-opening to see how a "small CSS change" can trigger repaints across your entire application.

4. Count Frames with requestAnimationFrame

Want to know if your fancy animation is actually hitting 60fps? Here's a DIY frame counter:

let frameCount = 0;
let lastTime = performance.now();
let fps = 0;

function countFrames(timestamp) {
  // Count this frame
  frameCount++;

  // If a second has passed, calculate FPS
  if (timestamp - lastTime >= 1000) {
    fps = frameCount;
    frameCount = 0;
    lastTime = timestamp;
    console.log(`Current FPS: ${fps}`);
  }

  // Schedule the next frame
  requestAnimationFrame(countFrames);
}

// Start counting
requestAnimationFrame(countFrames);

Drop this in your console while interacting with a complex animation to see exactly when performance drops. The beauty is you'll see the dips in real-time as you're testing different interactions. I found this invaluable when optimizing a data visualization that had acceptable FPS until users started dragging elements around.

5. Take Heap Snapshots to Catch Memory Leaks

Memory leaks in JavaScript can be deviously hard to spot. Instead of watching your app slow down over days, catch them in minutes:

In Chrome DevTools, go to the Memory tab
Select "Heap snapshot" and click "Take snapshot"
Perform the action you suspect is leaking (like opening/closing a modal several times)
Take another snapshot
Change the dropdown to "Comparison" to see what's growing

Look for objects that have suspiciously high retention counts—especially event listeners, detached DOM nodes, and closure variables.

These five techniques have helped me identify and fix performance bottlenecks in minutes instead of hours. They're not sexy, enterprise-grade monitoring solutions, but they get the job done when you need answers fast.

Next time you feel that sinking "why is this so slow?" feeling, remember these tools. Your users (and your future self) will thank you!

What's your favorite quick performance debugging trick? Drop a comment below and let's build a collection of developer lifesavers!

Buttery-Smooth Scroll Animations: Building a High-Performance Canvas Parallax Effect

Nidal tahir — Mon, 31 Mar 2025 20:08:33 +0000

👉 View and interact with the live demo on CodePen

Let's face it—we've all visited websites with those fancy scroll animations that somehow manage to turn your laptop into a stuttering mess. You know the ones I'm talking about: you scroll down and everything freezes for a second before jumping to catch up, making you wonder if you should just close the tab and go back to Instagram.

But it doesn't have to be that way. I've spent more late nights than I care to admit optimizing scroll animations, and I'm here to share how to build that slick scroll-based canvas animation you've been eyeing—the kind with shapes floating around, responding to your every scroll—without melting anyone's device.

⚡ TL;DR:

Want to build a buttery-smooth scroll animation with shapes that move in a parallax effect? The secret is: 1) use canvas instead of DOM elements, 2) implement proper throttling, 3) batch updates with requestAnimationFrame, 4) optimize for different devices, and 5) respect user preferences. I'll walk you through building it from scratch with performance as the #1 priority.

👀 Related:

If you're into making your UI faster overall, not just prettier—check out my deep dive on 8 JavaScript Helper Functions That Make Your UI Feel Instant. I shared practical tools like debounce, throttle, virtual scrolling, and more.

The Animation We're Building

First, let's get clear on what we're creating: a scroll-based animation where colorful shapes converge toward the center as you scroll down, with a title that fades in and scales slightly. It's a simple but effective parallax animation that adds visual interest without being distracting.

Here's what makes our implementation special:

It runs at 60fps even on mid-range mobile devices
It automatically adapts to different screen sizes and pixel densities
It respects user preferences (like reduced motion)
It doesn't drain your battery like a 5-year-old phone running Fortnite

Performance Bottlenecks: Why Most Scroll Animations Suck

Before diving into how to build ours properly, let's understand why so many scroll animations turn into slideshow presentations:

The DOM Is Not Your Friend - Each time you move 50+ DOM elements on scroll, you're begging for layout thrashing. The browser has to recalculate positions and repaint everything... repeatedly.
Event Tsunami - Scroll events fire like a machine gun—easily 30+ times per second. Doing heavy lifting on each one is performance suicide.
JavaScript Traffic Jams - Complex calculations on the main thread block everything else from happening. Users scroll, nothing moves, they scroll more, everything jumps. Rage ensues.
Device Blindness - Developers with beefy machines often forget that most people aren't rocking the latest M2 MacBook Pro. What works on your dev machine might crawl on the average user's device.
Battery Vampires - Poorly optimized animations don't just feel laggy—they actively drain batteries by constantly forcing the CPU and GPU to work overtime.

With those pitfalls in mind, let's build something that actually respects both users and their devices.

Setting Up Our HTML & CSS Foundation

First, the basic structure. Nothing fancy here, but pay attention to some of the CSS properties that help with performance:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Smooth Scroll Animation</title>
  <style>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    :root {
      --primary-color: #fff;
      --bg-color: #000;
    }

    body {
      font-family: -apple-system, BlinkMacSystemFont, 'Helvetica Neue', Arial, sans-serif;
      overflow-x: hidden;
      background-color: var(--bg-color);
      color: var(--primary-color);
    }

    .scroll-container {
      position: relative;
      /* Height will be set dynamically with JS */
    }

    .sticky-container {
      position: sticky;
      top: 0;
      height: 100vh;
      width: 100%;
      overflow: hidden;
      display: flex;
      justify-content: center;
      align-items: center;
      contain: layout paint style; /* Performance boost */
    }

    .canvas-container {
      position: absolute;
      top: 0;
      left: 0;
      width: 100%;
      height: 100%;
      will-change: transform; /* Hint to browser for optimization */
    }

    canvas {
      position: absolute;
      top: 0;
      left: 0;
      backface-visibility: hidden;
      transform: translateZ(0); /* Force GPU acceleration */
    }

    .title {
      position: absolute;
      top: 50%;
      left: 50%;
      transform: translate(-50%, -50%);
      font-size: 10vw;
      font-weight: 300;
      letter-spacing: -0.03em;
      text-align: center;
      white-space: nowrap;
      color: var(--primary-color);
      z-index: 10;
      opacity: 0;
      mix-blend-mode: difference;
      text-transform: uppercase;
      will-change: opacity, transform; /* Performance hint */
    }

    .progress {
      position: fixed;
      bottom: 0;
      left: 0;
      width: 100%;
      height: 2px;
      background: rgba(255, 255, 255, 0.1);
      z-index: 100;
    }

    .progress-bar {
      height: 100%;
      width: 0;
      background: var(--primary-color);
      will-change: width;
    }
  </style>
</head>
<body>
  <div class="progress"><div class="progress-bar"></div></div>
  <div class="scroll-container">
    <div class="sticky-container">
      <h1 class="title">REVELATION</h1>
      <div class="canvas-container">
        <canvas id="canvas"></canvas>
      </div>
    </div>
  </div>
  <script>
    // Our JavaScript will go here
  </script>
</body>
</html>

Notice those CSS properties like will-change, transform: translateZ(0), and contain? Those aren't just fancy buzzwords—they're direct signals to the browser about how to optimize rendering. We're essentially saying "Hey browser, these elements are going to change a lot, so prepare accordingly."

The JavaScript Engine: Where the Real Magic Happens

Now for the JavaScript. I'll break this down into manageable chunks and explain why each optimization matters:

1. Setting Up Our Foundation

(() => {
  // Core variables
  let canvas, ctx;
  let width, height;
  let shapes = [];
  let lastScrollY = 0;
  let maxScroll = 0;
  let needsUpdate = true;
  let animationFrameId = null;
  let isReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
  let isTabVisible = true;
  let shapeCache = null;
  let ticking = false;

  const scrollMultiplier = 5; // Controls scroll length
  const colors = ['#ff9500', '#ff2d55', '#5ac8fa', '#007aff', '#34c759', '#af52de'];

  // Debounce helper - essential for resize events
  function debounce(func, wait) {
    let timeout;
    return function() {
      const context = this, args = arguments;
      clearTimeout(timeout);
      timeout = setTimeout(() => func.apply(context, args), wait);
    };
  }
})();

I'm wrapping everything in an IIFE (Immediately Invoked Function Expression) to avoid polluting the global scope. It's a small thing, but every bit of optimization counts when you're building something performance-critical.

2. Setting Up the Canvas

function createCanvas() {
  canvas = document.getElementById('canvas');
  if (!canvas) return;

  // Performance boost with these context options
  ctx = canvas.getContext('2d', { 
    alpha: false,         // Don't need transparency = faster
    desynchronized: true, // Reduce latency
    colorSpace: 'srgb'    // Optimize color calculations
  });

  setScrollHeight();
  resizeCanvas();
}

function setScrollHeight() {
  const scrollContainer = document.querySelector('.scroll-container');
  if (scrollContainer) {
    const viewportHeight = window.innerHeight;
    // Make scroll area 5x viewport height
    scrollContainer.style.height = `${viewportHeight * scrollMultiplier}px`;
    maxScroll = viewportHeight * (scrollMultiplier - 1);
  }
}

function resizeCanvas() {
  // Handle retina displays properly, but limit scaling
  const dpr = Math.min(window.devicePixelRatio || 1, 2);
  width = window.innerWidth;
  height = window.innerHeight;

  canvas.width = width * dpr;
  canvas.height = height * dpr;
  canvas.style.width = `${width}px`;
  canvas.style.height = `${height}px`;

  ctx.scale(dpr, dpr);

  needsUpdate = true;
}

The canvas setup is where many developers leave performance on the table. Look at those context options—they make a real difference:

alpha: false tells the browser we don't need transparency, which saves compositing time
desynchronized: true reduces input latency
Setting canvas dimensions for retina displays is crucial, but I cap the pixel ratio at 2x because going higher has diminishing returns while eating more resources

Also notice how we're setting the scroll container height dynamically based on viewport size. This ensures the animation feels consistent on all devices instead of being too short on large screens or too long on small ones.

3. Creating the Shapes

function getOptimalShapeCount() {
  const screenSize = width * height;
  const isMobile = window.innerWidth <= 768;
  const isLowPower = isMobile && !matchMedia('(min-resolution: 2dppx)').matches;

  // Reduce density for low-power devices
  let density = Math.min(window.devicePixelRatio || 1, 2);
  if (isLowPower) density = 0.5;

  // Base count on screen size and adjust for reduced motion
  const baseCount = screenSize / (isReducedMotion ? 15000 : 10000);
  return Math.floor(baseCount * density);
}

function initShapes() {
  // Reuse shape cache if dimensions haven't changed
  if (shapeCache && width === shapeCache.width && height === shapeCache.height) {
    shapes = [...shapeCache.shapes];
    return;
  }

  shapes = [];

  // Calculate optimal shape count based on device capabilities
  const optimalCount = getOptimalShapeCount();
  const cellSize = Math.sqrt((width * height) / optimalCount);

  const cols = Math.floor(width / cellSize) + 1;
  const rows = Math.floor(height / cellSize) + 1;

  // Golden angle for visually pleasing distribution
  const goldenAngle = Math.PI * (3 - Math.sqrt(5));

  for (let i = 0; i < cols * rows; i++) {
    const col = i % cols;
    const row = Math.floor(i / cols);

    const x = (col / cols) * width * 1.1 - width * 0.05;
    const y = (row / rows) * height * 1.1 - height * 0.05;

    const shapeType = (col + row) % 5;
    const size = 30 + Math.random() * 50;
    const colorIndex = (col + row * 2) % colors.length;
    const color = colors[colorIndex];
    const rotation = i * goldenAngle;

    shapes.push({
      x,
      y,
      size,
      type: shapeType,
      color,
      rotation,
      originalX: x,
      originalY: y,
      delay: Math.random() * 0.3
    });
  }

  // Cache shapes for reuse
  shapeCache = {
    width,
    height,
    shapes: [...shapes]
  };
}

This is where the real performance magic starts. Instead of blindly generating thousands of shapes, we:

Calculate the optimal number based on screen size and device capabilities
Detect low-power devices and reduce density accordingly
Use caching to avoid regenerating shapes when not necessary
Arrange shapes using the golden angle for visual appeal without extra computation

This approach means a flagship phone might get 400 shapes while a budget phone gets 100—both looking good but running smoothly on their respective hardware.

4. Drawing Optimizations

// Pre-compute shape drawing functions
const shapeFunctions = [
  // Square
  (ctx, size) => {
    ctx.fillRect(-size/2, -size/2, size, size);
  },
  // Circle
  (ctx, size) => {
    ctx.beginPath();
    ctx.arc(0, 0, size/2, 0, Math.PI * 2);
    ctx.fill();
  },
  // Triangle
  (ctx, size) => {
    ctx.beginPath();
    ctx.moveTo(0, -size/2);
    ctx.lineTo(size/2, size/2);
    ctx.lineTo(-size/2, size/2);
    ctx.closePath();
    ctx.fill();
  },
  // Cross
  (ctx, size) => {
    const barWidth = size / 5;
    ctx.fillRect(-size/2, -barWidth/2, size, barWidth);
    ctx.fillRect(-barWidth/2, -size/2, barWidth, size);
  },
  // Diamond
  (ctx, size) => {
    ctx.beginPath();
    ctx.moveTo(0, -size/2);
    ctx.lineTo(size/2, 0);
    ctx.lineTo(0, size/2);
    ctx.lineTo(-size/2, 0);
    ctx.closePath();
    ctx.fill();
  }
];

function drawShape(shape, scrollProgress) {
  const { x, y, size, type, color, rotation } = shape;

  ctx.save();
  ctx.translate(x, y);
  ctx.rotate(rotation + scrollProgress * Math.PI);

  const fadePoint = shape.delay;
  const opacity = scrollProgress <= fadePoint ? 0 : 
                  scrollProgress > fadePoint + 0.3 ? 1 : 
                  (scrollProgress - fadePoint) / 0.3;

  ctx.globalAlpha = opacity;
  ctx.fillStyle = color;

  // Use pre-computed drawing function
  if (shapeFunctions[type]) {
    shapeFunctions[type](ctx, size);
  }

  ctx.restore();
}

Using an array of functions instead of a switch statement might seem like a small thing, but it actually matters. It's faster to look up an array index than to evaluate multiple conditions, especially when drawing hundreds of shapes dozens of times per second.

5. The Animation Loop

function updateAndDraw(timestamp) {
  animationFrameId = null;

  // Don't waste cycles when tab isn't visible
  if (!isTabVisible) {
    return;
  }

  // Only render when something changed
  if (!needsUpdate) {
    animationFrameId = requestAnimationFrame(updateAndDraw);
    return;
  }

  needsUpdate = false;

  ctx.clearRect(0, 0, width, height);

  const scrollProgress = Math.min(Math.max(lastScrollY / maxScroll, 0), 1);

  // Update progress bar
  const progressBar = document.querySelector('.progress-bar');
  if (progressBar) {
    progressBar.style.width = `${scrollProgress * 100}%`;
  }

  // Update title opacity and scale
  const title = document.querySelector('.title');
  if (title) {
    title.style.opacity = scrollProgress > 0.2 ? 1 : scrollProgress / 0.2;
    const titleScale = 0.8 + scrollProgress * 0.4;
    title.style.transform = `translate(-50%, -50%) scale(${titleScale})`;
  }

  // Limit shapes based on device capability and user preferences
  const visibleShapesCount = isReducedMotion ? Math.floor(shapes.length / 2) : shapes.length;
  const optimizedCount = Math.min(visibleShapesCount, 300); // Hard cap for performance
  const shapesToRender = shapes.slice(0, optimizedCount);

  // Render shapes with parallax movement
  for (let i = 0; i < shapesToRender.length; i++) {
    const shape = shapesToRender[i];

    // Calculate parallax movement
    const moveX = (shape.originalX - width/2) * scrollProgress * 1.5;
    const moveY = (shape.originalY - height/2) * scrollProgress * 1.5;

    shape.x = shape.originalX + moveX;
    shape.y = shape.originalY + moveY;

    drawShape(shape, scrollProgress);
  }

  animationFrameId = requestAnimationFrame(updateAndDraw);
}

Here's where a lot of performance magic happens:

We skip rendering completely when the tab isn't visible
We only redraw when something has actually changed
We limit the number of shapes to at most 300 (or fewer on lower-end devices)
For users with reduced motion preferences, we cut the number of shapes in half
We calculate all positions once per frame instead of multiple times

6. Event Handling and Throttling

function handleScroll() {
  lastScrollY = window.scrollY;

  // Throttle updates using requestAnimationFrame
  if (!ticking) {
    requestAnimationFrame(() => {
      needsUpdate = true;

      if (!animationFrameId && isTabVisible) {
        animationFrameId = requestAnimationFrame(updateAndDraw);
      }

      ticking = false;
    });

    ticking = true;
  }
}

const handleVisibilityChange = debounce(() => {
  isTabVisible = document.visibilityState === 'visible';

  if (isTabVisible && !animationFrameId) {
    needsUpdate = true;
    animationFrameId = requestAnimationFrame(updateAndDraw);
  }
}, 50);

const handleResize = debounce(() => {
  setScrollHeight();
  resizeCanvas();
  initShapes();
  needsUpdate = true;

  if (!animationFrameId && isTabVisible) {
    animationFrameId = requestAnimationFrame(updateAndDraw);
  }
}, 200);

This is probably the most critical part of making scroll animations feel smooth. Proper throttling and event handling can be the difference between butter-smooth scrolling and a janky mess:

We're using requestAnimationFrame for throttling scroll events (more efficient than time-based throttling)
Resize events are debounced with a 200ms delay (crucial since resize can fire hundreds of times during a single user action)
We track tab visibility to avoid wasting resources when the user isn't even looking at our animation

7. Initialization and Cleanup

function cleanup() {
  window.removeEventListener('scroll', handleScroll);
  window.removeEventListener('resize', handleResize);
  document.removeEventListener('visibilitychange', handleVisibilityChange);

  if (animationFrameId) {
    cancelAnimationFrame(animationFrameId);
    animationFrameId = null;
  }

  shapeCache = null;
}

function init() {
  createCanvas();
  initShapes();

  window.addEventListener('scroll', handleScroll, { passive: true });
  window.addEventListener('resize', handleResize, { passive: true });
  document.addEventListener('visibilitychange', handleVisibilityChange);

  if (isTabVisible) {
    needsUpdate = true;
    animationFrameId = requestAnimationFrame(updateAndDraw);
  }

  window.addEventListener('beforeunload', cleanup);

  // Listen for reduced motion preference changes
  const mediaQuery = window.matchMedia('(prefers-reduced-motion: reduce)');
  if (mediaQuery.addEventListener) {
    mediaQuery.addEventListener('change', () => {
      isReducedMotion = mediaQuery.matches;
      needsUpdate = true;

      if (!animationFrameId && isTabVisible) {
        animationFrameId = requestAnimationFrame(updateAndDraw);
      }
    });
  }
}

// Initialize the animation
if (document.readyState === 'loading') {
  document.addEventListener('DOMContentLoaded', init);
} else {
  window.requestIdleCallback ? window.requestIdleCallback(init) : setTimeout(init, 1);
}

The { passive: true } option on event listeners is a small but meaningful performance boost, especially for scroll events. It tells the browser that we won't be calling preventDefault(), allowing it to optimize accordingly.

Using requestIdleCallback (with a fallback to setTimeout) means our initialization happens when the browser is less busy, reducing the chance of jank during page load.

And proper cleanup is just good citizenship—nobody likes a memory leak.

Why This Approach Actually Works

So why is this approach so much better than moving a bunch of DOM elements with CSS transforms?

Canvas Efficiency: Drawing shapes on canvas is vastly more efficient than manipulating the DOM. When you have hundreds of elements, this difference becomes enormous.
Smart Throttling: By throttling scroll events with requestAnimationFrame, we're naturally syncing to the browser's render cycle instead of fighting against it.
Device-Aware Rendering: We're not assuming everyone has the latest hardware. By adapting the number and complexity of shapes based on the device, we ensure a smooth experience across the board.
Accessibility Considerations: The reduced motion detection means users who prefer less animation still get an engaging experience without potentially triggering issues like motion sickness.
Battery Friendliness: By rendering only when necessary and pausing when the tab isn't visible, we're being respectful of users' battery life.

Common Mistakes to Avoid

From my experiences building (and fixing) scroll animations, here are some traps you definitely want to avoid:

DOM Domination: Using DOM elements instead of canvas for large numbers of animated objects is asking for trouble. I once had to rescue a project where they tried animating 500+ divs on scroll. The browser was basically crying for mercy.
Scroll Event Overload: Handling scroll events without throttling is performance suicide. I've seen scroll handlers firing 100+ times during a single scroll movement.
Forgetting Mobile: Testing only on your developer machine is a recipe for disaster. What feels smooth on your Core i9 might bring a mid-range phone to its knees.
Ignoring User Preferences: Not accounting for reduced motion preferences might seem minor, but it can literally make some users physically ill. Always respect user preferences.
Layout Thrashing: Repeatedly reading and then writing to the DOM (like getting scroll position, then updating positions, then getting measurements again) can cause multiple forced reflows. Batch your reads and writes!

Conclusion

Building scroll animations that actually perform well isn't rocket science, but it does require some forethought and a genuine concern for user experience across all devices. The approach outlined here has served me well across multiple projects, and the principles apply even if you're building something completely different.

The next time you're tempted to animate 200 DOM elements on scroll—stop, breathe, and remember there's probably a more efficient way to achieve the same effect. Your users' devices (and batteries) will thank you.

👉 Check out the full code and live demo on CodePen

Happy scrolling! ✨

👋 If you enjoyed this article, you might also like my previous write-up: 8 JavaScript Helper Functions That Make Your UI Feel Instant

It’s packed with practical tools to make your UI not just beautiful—but fast.

What performance tricks do you use for smooth animations? Have you found other canvas optimizations that work well? Drop a comment below – I'd love to hear your experiences!

JavaScript Performance: 8 Essential Helper Functions to Boost Your UI

Nidal tahir — Sun, 30 Mar 2025 11:38:22 +0000

Let's be honest—we've all rage-clicked on a sluggish web app wondering if it's frozen or just ignoring us. Why do some websites feel buttery smooth while others make you want to throw your laptop out the window? After spending countless late nights debugging performance issues in production, I've realized it often boils down to how we handle UI events and rendering.

I'm not going to pretend I haven't shipped laggy UIs before—I definitely have. But through painful trial and error (and plenty of customer complaints), I've collected a toolbox of JavaScript helper functions that have saved my bacon time and again. Whether you're trying to tame a data-heavy dashboard that's bringing browsers to their knees or just trying to make your portfolio site feel snappier, these practical patterns have got your back.

⚡ TL;DR:

Slow UI? It's not always the framework's fault. Usually, it's too many DOM updates, rapid-fire events, or heavy JavaScript blocking the main thread. In this article, I'm sharing battle-tested JavaScript helpers (debounce, throttle, lazy loading, and more) that have saved me from late-night debugging nightmares. If you're ready to make your UIs faster and your users happier, keep reading!

Understanding Performance Bottlenecks
Debounce: Taming Rapid-Fire Events
Throttle: Steady Control for Frequent Events
RequestAnimationFrame Wrapper: Smooth Visual Updates
Virtual Scrolling Helper: Rendering Only What's Needed
Lazy Loading: Loading Resources Just in Time
Chunked Processing: Breaking Up Heavy Tasks
Memoization for Rendering: Don't Repeat Expensive Calculations
Event Delegation: Efficient Event Handling
Choosing the Right Helper Function
Conclusion and Next Steps

Understanding Performance Bottlenecks

Before we dive into the good stuff, let's quickly talk about what actually makes UIs slow. After profiling more websites than I care to admit, these five culprits keep showing up:

DOM update hell - Every time you touch the DOM, the browser potentially recalculates layouts. Do this too often, and your UI starts crawling.
Event tsunami - Try logging scroll events sometime. Your poor function might fire 30+ times per second! No wonder things get choppy.
JavaScript traffic jams - When your code hogs the main thread, nothing else gets processed—not clicks, not scrolls, nothing. Users hate this.
Calculation groundhog day - Recomputing the same values over and over is like hitting every red light on your commute. Utterly unnecessary.
Event listener bloat - Each listener takes memory and CPU cycles. Hundreds of them? That's a recipe for a sluggish experience.

The helper functions below have quite literally saved projects I've worked on. Let's start with the dynamic duo that should be in every frontend dev's toolkit: debounce and throttle.

Debounce: Taming Rapid-Fire Events

Think of debouncing like this: you're at a bar with a chatty friend who keeps starting new thoughts mid-sentence. Instead of responding to every half-formed idea, you wait until they take a breath before replying. That's debounce in a nutshell—it waits for a pause before acting.

What Problem Does Debounce Solve?

I once built a search feature that fired API requests with every keystroke. Typing "javascript" triggered 10 separate network calls—the "j" query returned Java results, then "ja" returned something else, creating a messy race condition. The customer complained about seeing flashes of wrong results. Debouncing fixed all of that by waiting until typing stopped before making a single request. Ever since that embarrassing disaster, debounce has been my trusty sidekick for any project with rapid-fire events. I've literally added it to my project starter templates—right up there with the things I never leave home without.

Implementation

/**
 * Creates a debounced version of a function that delays execution
 * until after wait milliseconds have elapsed since the last time it was invoked.
 * 
 * @param {Function} func - The function to debounce
 * @param {number} wait - The number of milliseconds to delay
 * @param {boolean} [immediate=false] - Whether to invoke the function on the leading edge
 * @return {Function} The debounced function
 */
function debounce(func, wait, immediate = false) {
  let timeout;

  return function executedFunction(...args) {
    const context = this;

    // Function to execute after the delay
    const later = function() {
      timeout = null;
      if (!immediate) func.apply(context, args);
    };

    const callNow = immediate && !timeout;

    // Reset the timer
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);

    // Call immediately if needed
    if (callNow) func.apply(context, args);
  };
}

Example Usage

// Without debounce - would fire many times during typing
searchInput.addEventListener('input', handleSearch);

// With debounce - only fires 300ms after typing stops
searchInput.addEventListener('input', debounce(handleSearch, 300));

function handleSearch(e) {
  // Run search query with input value
  fetchSearchResults(e.target.value);
}

Common Use Cases

Search inputs and filtering
Window resize handlers
Form input validation
Saving content while typing (like Google Docs)
Autocomplete/type-ahead features

Pitfalls to Avoid

I've set the delay too high (1000ms+) and had users ask if the feature was broken. Keep it snappy!
Going too low (like 50ms) pretty much defeats the purpose—I've made this mistake when debugging and forgotten to change it back.
Watch out for this context and event objects. I once spent hours debugging because my debounced function lost its event object. Facepalm moment.
Sometimes you want immediate feedback AND debouncing. That's what the immediate flag is for—like when validating forms where you want instant validation on the first keystroke but not every single one after.

Throttle: Steady Control for Frequent Events

If debounce is waiting for someone to shut up, throttle is more like "I'll hear you out, but only every 5 seconds." No matter how much they talk, you're only going to respond at regular intervals. This is clutch for events that fire like a machine gun (looking at you, scroll events).

What Problem Does Throttle Solve?

True story: I once built this fancy scroll-based animation without throttling. It worked fine on my beefy dev machine, but QA testing on a mid-range phone turned it into a slideshow. The scroll handler was firing 30+ times per second, killing performance. Throttling it to execute at most every 100ms made everything buttery smooth while still feeling responsive. The animation actually looked better because it wasn't trying to do too much.

Implementation

/**
 * Creates a throttled function that only invokes the provided function
 * at most once per every wait milliseconds.
 * 
 * @param {Function} func - The function to throttle
 * @param {number} wait - The number of milliseconds to throttle invocations to
 * @return {Function} The throttled function
 */
function throttle(func, wait) {
  let lastCall = 0;
  let timeout = null;

  return function executedFunction(...args) {
    const context = this;
    const now = Date.now();
    const timeSinceLastCall = now - lastCall;

    // If enough time has passed, call the function immediately
    if (timeSinceLastCall >= wait) {
      lastCall = now;
      func.apply(context, args);
    } else {
      // Otherwise, schedule a call for when the wait time has passed
      clearTimeout(timeout);
      timeout = setTimeout(() => {
        lastCall = Date.now();
        func.apply(context, args);
      }, wait - timeSinceLastCall);
    }
  };
}

Example Usage

// Without throttle - would fire too frequently during scrolling
window.addEventListener('scroll', updateScrollIndicator);

// With throttle - only fires every 100ms at most
window.addEventListener('scroll', throttle(updateScrollIndicator, 100));

function updateScrollIndicator() {
  const scrollTop = document.documentElement.scrollTop;
  const height = document.documentElement.scrollHeight - window.innerHeight;
  const scrolled = (scrollTop / height) * 100;

  document.getElementById('scroll-indicator').style.width = scrolled + '%';
}

Common Use Cases

Scroll event handlers
Mouse move/hover effects
Drag operations
Canvas drawing/game loop operations
Real-time data updates (like stock tickers)

Pitfalls to Avoid

Throttle isn't great when you absolutely need that final event. I've seen devs use throttle for "save draft" functionality and then wonder why the last few keystrokes sometimes get lost. Use debounce for that!
I've gone too aggressive with 500ms+ throttling on mousemove events and created this weird laggy feeling. For mouse-related stuff, stick closer to 100ms or less.
Some implementations let you choose between executing on the first event, last event, or both. Worth understanding the difference if your UX needs that level of fine-tuning.

Debounce vs. Throttle Visualization

This is a representative image to explain the difference. The red X marks represent rapid-fire events like keystrokes or scroll movements, while the green checkmarks show when your function actually executes. Throttle runs your function at regular intervals regardless of event frequency, while debounce waits until the events completely stop before running the function once. One approach gives you regular updates; the other prevents unnecessary work until you're finished.

RequestAnimationFrame Wrapper: Smooth Visual Updates

I avoided requestAnimationFrame for years because it seemed like overkill. Boy, was I wrong. It's basically the browser saying, "Hey, let me know what you want to draw, and I'll call you at the perfect time." A wrapper makes it easier to use and adds some niceties that the bare API doesn't provide.

What Problem Does rAF Wrapper Solve?

I learned this one the hard way. I had this slick progress indicator that updated as content loaded. Used standard DOM manipulation and it stuttered like crazy. The browser was trying to repaint after every tiny update, causing this ugly flickering effect. Switching to rAF was like magic—the browser batched all my visual changes into smooth frames, and users stopped complaining about the "glitchy" animation.

Implementation

/**
 * Wraps a function to ensure it runs in sync with the browser's render cycle.
 * Adds support for cancellation and once-only execution.
 * 
 * @param {Function} callback - The function to run on animation frame
 * @param {Object} [options] - Configuration options
 * @param {boolean} [options.once=false] - Run the callback only once
 * @return {Object} Controls for the animation frame
 */
function rafHelper(callback, { once = false } = {}) {
  let rafId = null;
  let cancelled = false;

  const animate = function(timestamp) {
    if (cancelled) return;

    callback(timestamp);

    if (!once && !cancelled) {
      rafId = requestAnimationFrame(animate);
    }
  };

  return {
    start() {
      if (!rafId && !cancelled) {
        rafId = requestAnimationFrame(animate);
      }
      return this;
    },
    cancel() {
      cancelled = true;
      if (rafId) {
        cancelAnimationFrame(rafId);
        rafId = null;
      }
      return this;
    },
    isPending() {
      return !!rafId;
    }
  };
}

Example Usage

// Smooth scrolling implementation
function smoothScrollTo(element) {
  const start = window.pageYOffset;
  const target = element.getBoundingClientRect().top + start;
  const distance = target - start;
  const startTime = performance.now();
  const duration = 1000; // ms

  const animation = rafHelper(function step(timestamp) {
    const elapsed = timestamp - startTime;
    const progress = Math.min(elapsed / duration, 1);
    const easeProgress = easeOutCubic(progress);

    window.scrollTo(0, start + distance * easeProgress);

    if (progress < 1) {
      // Continues automatically because rafHelper repeats by default
    } else {
      animation.cancel(); // Stop when we're done
    }
  }).start();

  // Return the animation controller so scrolling can be cancelled
  return animation;
}

function easeOutCubic(x) {
  return 1 - Math.pow(1 - x, 3);
}

Common Use Cases

Smooth animations
Scroll effects
DOM-based visualizations
Parallax effects
Performance monitoring

Pitfalls to Avoid

Don't nest rAF calls as this can lead to unpredictable timing
Be mindful of cleanup - always cancel animations when components unmount
Don't use excessive calculations in rAF callbacks as they can lead to dropped frames

Virtual Scrolling Helper: Rendering Only What's Needed

Virtual scrolling changed my life. It's a fancy term for a simple concept: only render what the user can actually see. Everything else? Smoke and mirrors.

What Problem Does Virtual Scrolling Solve?

I inherited this news portal with 3,000+ articles, each with its own image card. Opening the hub was painful – 20+ seconds to load while Chrome threw "page unresponsive" warnings. After implementing virtual scrolling, the difference was night and day. We only rendered the 15-20 news cards actually visible in the viewport, swapping in new ones as users scrolled.

Implementation

/**
 * Creates a virtual scroll container that efficiently renders only visible items
 * 
 * @param {Object} options - Configuration options
 * @param {HTMLElement} options.container - The container element
 * @param {Function} options.renderItem - Function to render a single item (index) => HTMLElement
 * @param {number} options.totalItems - Total number of items in the list
 * @param {number} options.itemHeight - Height of each item in pixels
 * @param {number} [options.overscan=5] - Number of items to render beyond visible area
 * @return {Object} Methods to control the virtual list
 */
function virtualScroller({
  container,
  renderItem,
  totalItems,
  itemHeight,
  overscan = 5
}) {
  let scrollTop = 0;
  let visibleItems = [];
  const contentHeight = totalItems * itemHeight;

  // Create placeholder to maintain scroll height
  const placeholder = document.createElement('div');
  placeholder.style.height = `${contentHeight}px`;
  placeholder.style.position = 'relative';
  container.appendChild(placeholder);

  function updateVisibleItems() {
    // Calculate visible range with overscan
    const viewportHeight = container.clientHeight;
    scrollTop = container.scrollTop;

    const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan);
    const endIndex = Math.min(
      totalItems - 1,
      Math.ceil((scrollTop + viewportHeight) / itemHeight) + overscan
    );

    // Remove all current items
    while (placeholder.firstChild) {
      placeholder.removeChild(placeholder.firstChild);
    }

    // Add newly visible items
    for (let i = startIndex; i <= endIndex; i++) {
      const item = renderItem(i);
      item.style.position = 'absolute';
      item.style.top = `${i * itemHeight}px`;
      item.style.height = `${itemHeight}px`;
      item.style.left = '0';
      item.style.right = '0';
      placeholder.appendChild(item);
    }

    visibleItems = Array.from({ length: endIndex - startIndex + 1 }, (_, i) => startIndex + i);
  }

  // Initial render
  updateVisibleItems();

  // Listen for scroll events with throttle
  container.addEventListener('scroll', throttle(updateVisibleItems, 16)); // ~60fps

  return {
    refresh: updateVisibleItems,
    getVisibleItems: () => visibleItems,
    scrollToItem(index) {
      container.scrollTop = index * itemHeight;
    }
  };
}

Example Usage

const listContainer = document.getElementById('list-container');

const virtualList = virtualScroller({
  container: listContainer,
  totalItems: 10000, // Imagine rendering 10,000 items!
  itemHeight: 40,
  renderItem: (index) => {
    const item = document.createElement('div');
    item.className = 'list-item';
    item.textContent = `Item #${index + 1}`;
    return item;
  }
});

// Later, if data changes:
virtualList.refresh();

// Jump to a specific item:
document.getElementById('jump-btn').addEventListener('click', () => {
  virtualList.scrollToItem(5000); // Jump to the middle
});

Common Use Cases

Long lists or tables of data
Social media feeds
Chat applications
Large spreadsheets
Search results

Pitfalls to Avoid

Variable height items require more complex implementations
Don't forget to update when window is resized
Consider adding key-based rendering for React-like frameworks
Be careful with focus management when items appear/disappear

Lazy Loading: Loading Resources Just in Time

Lazy loading is like good procrastination—putting off work until you absolutely have to do it. Why load 50 product images when the user can only see 5?

What Problem Does Lazy Loading Solve?

I worked on a furniture design website that was taking forever to load. We're talking 15MB of high-res images hitting the network on page load - sofas, dining tables, and decor pieces in stunning detail that the client insisted had to be ultra high-quality. During development, we realized this would be completely unacceptable to deliver - it would have been embarrassing. After implementing lazy loading, initial page load dropped to under 200kb, and images loaded just as users scrolled to them. Load time went from "go make coffee" to "blink and you'll miss it." The client thought we'd compressed all their precious furniture images (we hadn't)—we just delayed loading them until needed.

Implementation

/**
 * Creates a helper to lazy load images as they approach the viewport
 * 
 * @param {Object} [options] - Configuration options
 * @param {string} [options.selector='img[data-src]'] - Selector for lazy images
 * @param {number} [options.rootMargin='200px'] - Margin around viewport for preloading
 * @param {string} [options.srcAttribute='data-src'] - Attribute containing the image URL
 * @return {Object} Lazy loading controller
 */
function lazyLoader({
  selector = 'img[data-src]',
  rootMargin = '200px',
  srcAttribute = 'data-src'
} = {}) {
  let observer;
  const loadedImages = new Set();

  function loadImage(img) {
    if (loadedImages.has(img)) return;

    const src = img.getAttribute(srcAttribute);
    if (!src) return;

    // Start loading the image
    img.src = src;
    img.removeAttribute(srcAttribute);

    // Mark as loaded and dispatch event when fully loaded
    img.addEventListener('load', () => {
      loadedImages.add(img);
      img.dispatchEvent(new CustomEvent('lazyloaded'));
    });
  }

  function init() {
    // Use Intersection Observer API if available
    if ('IntersectionObserver' in window) {
      observer = new IntersectionObserver((entries) => {
        entries.forEach(entry => {
          if (entry.isIntersecting) {
            loadImage(entry.target);
            observer.unobserve(entry.target);
          }
        });
      }, { rootMargin });

      // Observe all matching elements
      document.querySelectorAll(selector).forEach(img => {
        if (!loadedImages.has(img)) {
          observer.observe(img);
        }
      });
    } else {
      // Fallback for browsers without IntersectionObserver
      document.querySelectorAll(selector).forEach(loadImage);
    }
  }

  function disconnect() {
    if (observer) {
      observer.disconnect();
    }
  }

  return {
    init,
    disconnect,
    loadImage, // Expose to manually load specific images
    refresh() { // For when new images are added to the DOM
      disconnect();
      init();
    }
  };
}

Example Usage

<!-- HTML structure -->
<img data-src="large-image-1.jpg" src="tiny-placeholder.jpg" alt="Description">
<img data-src="large-image-2.jpg" src="tiny-placeholder.jpg" alt="Description">

// Initialize lazy loading
const lazyImages = lazyLoader();
lazyImages.init();

// When new content is loaded via AJAX:
fetchMoreContent().then(() => {
  lazyImages.refresh();
});

Common Use Cases

Image galleries
Long content pages with many images
Product listings
Media-heavy websites
Embedded videos

Pitfalls to Avoid

Always provide a placeholder or low-res version for initial render
Be careful with layout shifts when images load
Consider adding loading animations for better user experience
Think about no-JavaScript fallbacks for SEO and accessibility

Chunked Processing: Breaking Up Heavy Tasks

Chunked processing is kind of like how you'd eat an elephant: one bite at a time (not that I'm advocating eating elephants). Big tasks lock up the browser, so we break them into small digestible chunks.

What Problem Does Chunked Processing Solve?

This one hits close to home. I had built this data-visualization tool that needed to process thousands of records. Everything worked in testing, but once we got real user data... disaster. The app would freeze for up to 10 seconds while crunching numbers. Users thought it had crashed. By chunking the work into small batches and using a progress indicator, not only did the UI stay responsive, but users actually felt better seeing the progress rather than staring at a frozen screen. The actual processing took about the same total time, but the perceived performance was night and day.

Implementation

/**
 * Process a large array of items in chunks to avoid blocking the UI thread
 * 
 * @param {Array} items - Array of items to process
 * @param {Function} processItem - Function to process a single item
 * @param {Object} [options] - Configuration options
 * @param {number} [options.chunkSize=100] - Number of items to process per chunk
 * @param {number} [options.delayBetweenChunks=0] - Delay in ms between chunks
 * @return {Promise} Resolves when all processing is complete
 */
function processInChunks(items, processItem, { 
  chunkSize = 100, 
  delayBetweenChunks = 0 
} = {}) {
  return new Promise((resolve) => {
    const total = items.length;
    let processed = 0;

    function processNextChunk() {
      const start = processed;
      const end = Math.min(processed + chunkSize, total);

      // Process this chunk
      for (let i = start; i < end; i++) {
        processItem(items[i], i);
      }

      processed = end;

      // Report progress
      const progress = processed / total;
      const detail = { processed, total, progress };
      window.dispatchEvent(new CustomEvent('chunkProcessed', { detail }));

      // Check if we're done
      if (processed >= total) {
        resolve();
        return;
      }

      // Schedule next chunk
      if (delayBetweenChunks > 0) {
        setTimeout(processNextChunk, delayBetweenChunks);
      } else {
        requestAnimationFrame(processNextChunk);
      }
    }

    // Start processing
    processNextChunk();
  });
}

Example Usage

// Process 10,000 data points without freezing the UI
const largeDataset = Array.from({ length: 10000 }, (_, i) => ({ id: i, value: Math.random() }));

// Show progress indicator
const progressBar = document.getElementById('progress-bar');
window.addEventListener('chunkProcessed', (e) => {
  progressBar.style.width = `${e.detail.progress * 100}%`;
  progressBar.textContent = `${Math.round(e.detail.progress * 100)}%`;
});

// Start processing
processInChunks(largeDataset, (item) => {
  // Do something computationally expensive with each item
  item.processed = complexCalculation(item.value);

  // Optionally update the DOM (carefully)
  if (item.value > 0.95) {
    addToHighValueList(item);
  }
}, { chunkSize: 200 }).then(() => {
  console.log('All processing complete!');
  showResults(largeDataset);
});

Common Use Cases

Processing large datasets
Complex DOM transformations
Text analysis
Data visualization preparation
Batch API requests

Pitfalls to Avoid

Don't make DOM modifications in every iteration (batch them)
Choose an appropriate chunk size (too small = overhead, too large = lag)
Be mindful of memory usage when processing large datasets
Consider using Web Workers for very intensive calculations

Memoization for Rendering: Don't Repeat Expensive Calculations

Memoization is just fancy caching. It's like telling your code, "Hey, if I ask for the 23rd Fibonacci number twice, don't recalculate it—just remember what you told me the first time."

What Problem Does Memoization Solve?

I once worked on a tool that calculated carbon footprints for websites and saved analysis history. Every time someone viewed a past analysis or toggled between different metrics, we'd recalculate the SAME carbon data over and over. We'd fetch the complete JSON with all the resources and redo every calculation from scratch, taking the same amount of time as the initial analysis despite using data we'd already processed. One particular set of emissions calculations took 300ms on a moderate-sized site. I caught this during development when I noticed the same calculations running repeatedly in the console logs. After adding memoization, subsequent calls returned instantly. Same code, same results, just not doing the same work repeatedly. The performance difference was so dramatic that I couldn't believe I'd missed something so obvious - we were essentially acting like we'd never seen the data before, even though we were processing identical inputs over and over.

Implementation

/**
 * Creates a memoized version of a function that remembers results for input combinations
 * 
 * @param {Function} fn - The function to memoize
 * @param {Function} [keyFn] - Optional function to generate cache keys (defaults to JSON.stringify)
 * @return {Function} Memoized function
 */
function memoize(fn, keyFn = JSON.stringify) {
  const cache = new Map();

  function memoized(...args) {
    const key = keyFn(args);

    if (cache.has(key)) {
      return cache.get(key);
    }

    const result = fn.apply(this, args);
    cache.set(key, result);
    return result;
  }

  // Expose the cache for inspection or clearing
  memoized.cache = cache;
  memoized.clearCache = () => cache.clear();

  return memoized;
}

Example Usage

// Expensive function to calculate layout positions
function calculateNodePositions(nodes, width, height, iterations) {
  console.log('Running expensive layout calculation...');
  // Imagine complex force-directed graph layout algorithm here
  return nodes.map(node => ({ 
    ...node,
    x: Math.random() * width,
    y: Math.random() * height
  }));
}

// Memoized version
const getMemoizedLayout = memoize(calculateNodePositions);

// Now we can call it multiple times with same parameters without penalty
const nodes = [{id: 1}, {id: 2}, {id: 3}];
const layout1 = getMemoizedLayout(nodes, 800, 600, 500); // Calculates
const layout2 = getMemoizedLayout(nodes, 800, 600, 500); // Returns cached result

// Only recalculates when inputs change
const layout3 = getMemoizedLayout(nodes, 1024, 768, 500); // Recalculates

Common Use Cases

Complex layout calculations
Data transformations for visualization
Expensive string operations
Recursive functions with overlapping subproblems
Component rendering in frameworks like React

Pitfalls to Avoid

Be careful with memory usage for large cached results
The default key function may not work for complex objects
Be aware that memoization keeps references to objects
Consider cache clearing strategies for long-running applications

Event Delegation: Efficient Event Handling

Event delegation is pure genius—instead of giving instructions to each employee (DOM element), you tell their manager, "Just forward me anything important from your team." One listener instead of hundreds.

What Problem Does Event Delegation Solve?

I once debugged a memory leak in a website with complex interactive components. The site had a car configurator and a colorizer feature that let users customize their vehicle, but it would get slower and slower as you used it, eventually crawling to a halt. The culprit? Every time the configurator updated its options, we were adding new click handlers to each component and color swatch... without removing the old ones. With dozens of configurable parts and color options that changed based on selections, we were piling up thousands of zombie event listeners. Switching to a single delegated event on the container fixed the leak instantly. The configurator stayed snappy even after hours of tweaking options. Added bonus: new components and colors automatically worked without any extra code to bind events.

Implementation

/**
 * Creates an event delegation handler for efficient event management
 * 
 * @param {HTMLElement} element - Parent element to attach the event to
 * @param {string} eventType - Type of event to listen for (e.g., 'click')
 * @param {string} selector - CSS selector to match target elements
 * @param {Function} handler - Event handler function(event, matchedElement)
 * @return {Object} Methods to manage the delegated event
 */
function delegate(element, eventType, selector, handler) {
  function delegatedFunction(e) {
    // Find the matching element by traversing up from the event target
    let target = e.target;
    while (target && target !== element) {
      if (target.matches(selector)) {
        // Call the handler with the event and matched element
        handler.call(target, e, target);
        return;
      }
      target = target.parentElement;
    }
  }

  // Attach the delegated event handler
  element.addEventListener(eventType, delegatedFunction, false);

  // Return controls for removing or updating
  return {
    destroy() {
      element.removeEventListener(eventType, delegatedFunction, false);
    },
    update(newHandler) {
      handler = newHandler;
    }
  };
}

Example Usage

// Instead of adding click handlers to each button...
document.querySelectorAll('.product-card button.add-to-cart').forEach(button => {
  button.addEventListener('click', handleAddToCart); // BAD: Many listeners
});

// Use a single delegated handler
const cartHandler = delegate(document.querySelector('.product-grid'), 'click', 'button.add-to-cart', (e, button) => {
  e.preventDefault();

  const card = button.closest('.product-card');
  const productId = card.dataset.productId;

  addToCart(productId);
  button.textContent = 'Added to Cart';
  button.disabled = true;
});

// Later cleanup when needed
function unmountProductGrid() {
  cartHandler.destroy();
}

Common Use Cases

Lists of similar interactive elements
Tables with interactive cells
Dynamic content (elements added/removed frequently)
Form validation
Navigation menus

Pitfalls to Avoid

Don't use for events that don't bubble (focus, blur, etc.)
Remember that this in the handler refers to the matched element
Use caution with complex selectors that might be slow to match
Consider performance when delegation parent contains many elements

Choosing the Right Helper Function

I'm a firm believer in using the right tool for the job. After bombing a few projects by picking the wrong approach, here's my cheat sheet:

If You Need To...	Reach For This	Or Maybe This Instead
Handle typing or resize	Debounce	Throttle (when you need regular feedback)
Deal with scroll madness	Throttle	rAF Wrapper (when updating visuals)
Make buttery animations	rAF Wrapper	Web Animations API (simpler cases)
Make massive lists not suck	Virtual Scrolling	Chunked Rendering (for static content)
Speed up initial page load	Lazy Loading	Browser's native `loading="lazy"` (for basic cases)
Crunch numbers without freezing	Chunked Processing	Web Workers (for truly heavy calculations)
Stop calculating the same crap	Memoization	Framework computed props (React useMemo, etc.)
Manage thousands of clickables	Event Delegation	Component systems with built-in delegation

Conclusion and Next Steps

We've all seen plenty of sluggish websites out there. These helper functions have rescued my projects repeatedly, transforming frustrating experiences into smooth ones. They aren't silver bullets, but they make a world of difference when implemented thoughtfully.

Have performance horror stories or your own helper function variations? Share them in the comments! The best optimization tricks come from collective wisdom, and we all benefit from exchanging battle-tested solutions.

Further Learning Resources

MDN's Web Performance docs
Chrome DevTools Performance panel – worth learning
High Performance JavaScript by Nicholas Zakas – still relevant despite its age

Now go make something fast! ⚡

If this helped you out, a follow would make my day! I write about the painful performance lessons I've learned so you don't have to suffer like I did. And hey, if you know someone wrestling with laggy UIs, sharing might save their sanity.

DEV Community: Nidal tahir

How I Built a Secure, Scalable Auth System in Next.js 15 (with JWT, Edge Middleware, and Drizzle)

Why This Architecture?

Authentication Flow Overview

The Tech Stack

Core Authentication Flow

1. User Registration

2. Route Protection with Middleware

3. API Route Implementation

Database Design & ORM Choice

Why Drizzle ORM?

SQLite vs PostgreSQL

Security Best Practices Implemented

1. Password Security

2. Token Security

3. Input Validation

4. Error Handling

Performance Optimizations

1. Edge Middleware

2. Efficient Database Queries

3. Database Strategy: SQLite vs PostgreSQL

4. Component Optimization

Deployment Considerations

Local Development

Production Deployment

Testing Your Implementation

What's Next?

Get the Complete Code

Contributing

Lean Thinking in Engineering Development: Maximizing Value, Minimizing Waste

Introduction

Core Principles of Lean in Engineering Context

1. Identify Value from the Customer's Perspective

2. Spot and Remove Waste

3. Create Flow by Limiting Work-in-Progress

4. Use Pull Systems

5. Keep Improving (Kaizen)

AI: The New Boost for Lean Engineering

Quick-Start Implementation

Conclusion

Using Physics to Create Realistic 3D Effects in the Browser

Why Physics Matters in 3D

Step 1: Creating Depth Perception

Step 2: Adding Forces

Step 3: Natural Light Behavior

Step 4: Adding Organic Movement

Step 5: Depth Sorting

The Final Touch: Interactive Forces

Why It Works

How to Make Your NextJS App Painfully Slow 🐢💤

1. Say No to Image Optimization

2. Load Everything Upfront Because YOLO

3. Treat Server Components Like They're Radioactive

4. Build Edge Functions That Would Make AWS Blush

5. Re-render All The Things

6. Run Expensive Calculations in All the Wrong Places

The Truth Behind the Joke

🚨 5 Performance Debugging Tricks Every Web Dev Should Know (But Most Don't)

1. console.time()

2. Performance API for Super-Precise Timing

3. Paint Flashing — See What's Actually Repainting

4. Count Frames with requestAnimationFrame

5. Take Heap Snapshots to Catch Memory Leaks

Buttery-Smooth Scroll Animations: Building a High-Performance Canvas Parallax Effect

The Animation We're Building

Performance Bottlenecks: Why Most Scroll Animations Suck

Setting Up Our HTML & CSS Foundation

The JavaScript Engine: Where the Real Magic Happens

1. Setting Up Our Foundation

2. Setting Up the Canvas

3. Creating the Shapes

4. Drawing Optimizations

5. The Animation Loop

6. Event Handling and Throttling

7. Initialization and Cleanup

Why This Approach Actually Works

Common Mistakes to Avoid

Conclusion

JavaScript Performance: 8 Essential Helper Functions to Boost Your UI

Table of Contents

1. `console.time()`