DEV Community: Muhammad Tanveer

Halftone type in WebGL, one draw call per headline

Muhammad Tanveer — Tue, 27 Oct 2026 09:34:54 +0000

Every large title on this site is drawn as halftone dots. They fly in and assemble after the preloader, push away from the cursor and scatter as you scroll. It looks like an image effect, but the text is real: you can select it, search it, and a screen reader reads it like any other heading. This note covers how that works and what it costs.

Keep the text, paint over it

The component, DotText, renders the heading as normal HTML and lays a canvas over it. Once the WebGL scene is ready the element gets an is-live class, which makes the glyphs transparent while keeping them in the DOM. If WebGL is missing, the context is lost or the page runs in forced-colours mode, the canvas is hidden and an SVG filter draws a static halftone instead. Without JavaScript you get that static version too.

That split decides most of the rest: layout, wrapping and font loading all belong to CSS, and the canvas only has to copy what the browser already laid out.

Sampling the glyphs the browser drew

Rendering the string again with fillText would wrap and kern differently from the DOM. So the sampler walks the element’s text nodes and uses a Range to read each character’s client rect. Each glyph is drawn on an offscreen 2D canvas at exactly that position, with a horizontal scale that matches the DOM advance in case the canvas picks a slightly different width.

The display face is a variable font set to a condensed width, and canvas fonts don’t take font-variation-settings. The closest you get is ctx.fontStretch, so the computed font-stretch percentage is mapped to the nearest keyword (extra-condensed for this face).

From coverage to dot sizes

The alpha channel of that canvas is the ink coverage. Two box-blur passes per axis approximate a gaussian, so coverage falls off smoothly at the edge of each stroke. A grid is then laid over the result, and each cell becomes one dot whose radius follows the blurred coverage under it:

const r = (pitch / 2) * Math.min(0.92, v * 0.8 - 0.08)
if (r < 0.35) continue // too small to see; skip the point entirely
home.push(x - pad, y - pad)
rs.push(r)

Dots are full inside a stroke and shrink towards its edge, the same screen the SVG fallback produces, so the two versions match. The grid pitch is 6px on desktop and 4px below 720px, where type is smaller and needs a finer screen to stay readable.

All the motion lives in the vertex shader

Each dot gets its home position, radius and four random numbers as attributes, uploaded once. Everything that moves is a uniform: intro progress, scroll scatter, time and the cursor position. The vertex shader works out each dot’s position from those, so a frame is a handful of uniform* calls and one drawArrays(gl.POINTS), whether the title has 2,000 dots or 20,000.

// Intro: each dot flies in from its own offset with its own delay
float t = clamp(uProgress * 1.8 - aRand.w * 0.8, 0.0, 1.0);
float e = 1.0 - pow(1.0 - t, 3.0);
vec2 pos = uOrigin + aHome + aRand.xy * uSpread * (0.4 + aRand.w) * (1.0 - e);

// Cursor repulsion
vec2 d = pos - uMouse;
float len = length(d);
float f = (1.0 - smoothstep(0.0, uRadius, len)) * uMouseStrength;
pos += d / max(len, 0.001) * f * uPush;

The fragment shader draws an anti-aliased disc from gl_PointCoord and blends towards the accent colour by how hard the cursor is pushing that dot. Colour is read from the element’s computed color, so theme switches and hover transitions carry over without extra code.

Building lazily

Sampling is the expensive part: reading pixels back and blurring them is main-thread work. The first version built every title on load, including the footer, and it showed up as long tasks. Now an IntersectionObserver with a half-viewport margin decides when a title is near enough to sample, and the ticker skips titles that are off-screen or in a hidden tab. A ResizeObserver and document.fonts.ready mark the scene dirty, and it rebuilds on the next frame only if it is near the viewport.

Under prefers-reduced-motion the dots are drawn once, at rest, and repainted only when the colour changes. No ticker runs at all.

What I would keep

Leave the text in the DOM. The effect is decoration on top of a heading, and it never replaces one.
Sample what the browser rendered instead of re-implementing text layout.
Put the per-frame work in a shader and keep the CPU side to uniforms.
Do the costly setup only when the element is about to be seen.

Originally published on my site. I'm Muhammad Tanveer, a full-stack developer in Faisalabad, Pakistan: muhammad-tanveer-dev.vercel.app.

A shared-element page transition in the Next.js App Router

Muhammad Tanveer — Tue, 27 Oct 2026 09:34:27 +0000

When you open a project from the work index on this site, its cover grows from the list to fill the screen, the project name rises in, and the frame lifts away to show the case study. It works across routes in the Next.js App Router, in every browser, without the View Transitions API.

The pieces

TransitionLink: a normal <a> that intercepts plain left clicks and asks for an exit before calling router.push.
PageTransitionOverlay: lives in the root layout, so it survives navigation. It owns the overlay elements and all the timelines.
A small module, lib/transition.ts, that connects the two with a registered function instead of React context.

The overlay registers its exit function on mount, and the link calls it. Context would have meant a client provider around the whole tree just to pass one callback around.

let _playExit: ExitFn = (cb) => cb()

export function setExitFn(fn: ExitFn) {
  _playExit = fn
}

export function triggerExit(cb: () => void, label?: string, from?: MorphFrom | null) {
  _playExit(cb, label, from)
}

The default just navigates, so if the overlay isn’t mounted, links still work.

Respect the browser first

Before anything animates, the link lets the browser handle Cmd/Ctrl/Shift/Alt clicks and middle clicks, so opening a case study in a new tab works as usual. With reduced motion turned on, the exit function calls straight through to navigation.

Measuring the shared element

The morph source is the image’s clipping frame, not the image itself, because covers are cropped with object-fit and their own box can be larger than what you see. If the frame is tiny or off-screen, there’s nothing sensible to grow from, so the link falls back to the plain ink panel:

const rect = frame.getBoundingClientRect()
const onScreen = rect.width > 40 && rect.height > 24 && rect.bottom > 0 && rect.top < window.innerHeight
const src = img.currentSrc || img.src
return onScreen && src ? { rect, src } : null

No blank frame

The overlay image is given the same URL the page is already showing (currentSrc, so the same next/image rendition), which makes it a cache hit. It still waits for img.decode() before the first frame, otherwise there is a single empty frame at the start of the grow that you can see on slower machines.

Thumbnails are small, though, and a 640px image stretched to full screen looks soft. While the frame grows, a full-width rendition is requested by rewriting the w= parameter of the optimised image URL. It is swapped in only if it decodes while the overlay is still covering the screen.

Grow, navigate, lift

The grow is a GSAP timeline on left/top/width/height and the corner radius, with expo.inOut. When it completes it calls router.push. At the end the frame switches from measured pixels to 100%, so a resize while the next route loads doesn’t leave a gap.

The overlay watches usePathname(). When the path changes it scrolls to the top, waits one animation frame so the new page can register its ScrollTriggers, refreshes them, and then reveals: the label leaves first, then the frame slides up while the picture inside it moves down. Because the image lags behind its frame, the exit reads as a curtain rather than a card sliding away.

Never trap the user

Navigation can stall on a slow network or fail outright. A five-second timeout reveals the page regardless, so nobody is left staring at a full-screen image. The overlay is aria-hidden and focus never moves into it; to assistive technology this is an ordinary link to an ordinary page.

Originally published on my site. I'm Muhammad Tanveer, a full-stack developer in Faisalabad, Pakistan: muhammad-tanveer-dev.vercel.app.

Cutting Total Blocking Time from 200–500ms to 60–80ms

Muhammad Tanveer — Tue, 27 Oct 2026 09:34:01 +0000

This site has a Three.js portrait in the hero and WebGL halftone type on every page title. In local Lighthouse runs (desktop profile) Total Blocking Time sat between 200 and 500ms and the layout shifted by 0.15–0.25 on first load. After the changes below, TBT is around 60–80ms, CLS is close to zero and LCP is 0.9–1.4s. None of the effects were removed.

Find where the time goes

TBT adds up the part of every main-thread task over 50ms between first paint and interactive. Here, that time came from setup work: initialising Three.js, sampling every halftone title on the page (including ones a full scroll away), and canvases sized at the device’s full pixel ratio.

1. Ship Three.js only to the browser, after hydration

The portrait is imported with next/dynamic and ssr: false. Three.js is no longer in the main bundle and its setup runs after hydration rather than during it. The hero keeps its space with CSS, so nothing moves when the canvas arrives, and if WebGL fails it swaps in a plain image.

// Three.js only ships to the browser, after hydration.
const PortraitField = dynamic(() => import('./PortraitField'), { ssr: false })

2. Do expensive setup only near the viewport

Each halftone title reads its glyphs back from a canvas and blurs them, which takes real main-thread time. Every title used to do this on load. Now an IntersectionObserver with a 50% root margin gates both the build and the render loop. Titles far down the page, like the footer wordmark, wait until you scroll towards them, and nothing renders while it is off-screen or the tab is hidden.

const io = new IntersectionObserver(
  ([entry]) => {
    near = entry.isIntersecting
    if (near && dirty) rebuild()
  },
  { rootMargin: '50% 0px' }
)

3. Cap the pixel ratio

A 3x phone screen means nine times the fragments of a 1x screen, and halftone dots don’t get noticeably sharper past 2x. The canvases cap the device pixel ratio at 2, and at 1.5 on devices with four cores or fewer, or with Data Saver turned on.

4. Fix the layout shift at the source

Most of the CLS came from the web fonts. The condensed display face is much narrower than its fallback, so headlines rewrapped when it loaded. On a first visit, while the preloader is up anyway, a small inline script now hides the page until the three fonts have loaded, capped at two seconds. Repeat visits and reduced-motion users skip the wait entirely.

5. Put budgets in CI

Numbers drift without a check. Every pull request runs Lighthouse CI with budgets: LCP under 2s and CLS under 0.05 fail the build, accessibility and SEO under 0.95 fail it too, and TBT over 200ms raises a warning (lab runs have no INP, so TBT stands in for it).

What mattered most

Most of the cost was work done too early, not work that was too slow. Deferring it was enough.
Gate WebGL on visibility: build near the viewport and stop rendering off-screen.
Fix CLS where it starts (fonts), instead of reserving space around every heading.
Measure with budgets in CI, so a regression shows up on the pull request that caused it.

Originally published on my site. I'm Muhammad Tanveer, a full-stack developer in Faisalabad, Pakistan: muhammad-tanveer-dev.vercel.app.

Mastering the Core Concepts of Angular

Muhammad Tanveer — Tue, 02 Apr 2024 12:47:03 +0000

Angular is a comprehensive framework for building dynamic and interactive web applications. To harness its full potential, developers must grasp its core concepts, which form the backbone of Angular development. In this article, we'll explore these fundamental concepts in detail, accompanied by illustrative examples.

1. Components

Components are the building blocks of Angular applications. They encapsulate the logic, data, and UI elements of a specific part of the application. Here's an example of a simple Angular component:

import { Component } from '@angular/core';

@Component({
  selector: 'app-greeting',
  template: '<h1>Hello, {{ name }}!</h1>',
})
export class GreetingComponent {
  name: string = 'John';
}

In this example, GreetingComponent is a basic Angular component that displays a greeting message with the name "John." The @Component decorator defines the component's metadata, including its selector and template.

2. Directives

Angular directives are markers on a DOM element that tell Angular to do something with that element. There are two types of directives: structural directives and attribute directives.

Structural Directives:

<div *ngIf="isLoggedin">Welcome, User!</div>

In this example, *ngIf is a structural directive that conditionally renders the <div> element based on the value of the isLoggedin property.

Attribute Directives:

<input type="text" [ngModel]="username">

Here, ngModel is an attribute directive that establishes two-way data binding between the <input> element and the username property in the component class.

3. Services

Services are reusable components in Angular that encapsulate common functionality and data manipulation tasks. They are typically injected into Angular components or other services to provide specific functionalities.

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class DataService {
  getData() {
    return ['Item 1', 'Item 2', 'Item 3'];
  }
}

In this example, DataService is a service that provides a method getData() to fetch an array of items. The @Injectable decorator marks the class as a service, and providedIn: 'root' registers it with the root injector.

4. Dependency Injection (DI)

Angular uses dependency injection to provide components and services with the dependencies they need. Dependencies are declared in the constructor of a component or service, and Angular's injector automatically resolves and injects them.

import { Component } from '@angular/core';
import { DataService } from './data.service';

@Component({
  selector: 'app-item-list',
  template: `
    <ul>
      <li *ngFor="let item of items">{{ item }}</li>
    </ul>
  `,
})
export class ItemListComponent {
  items: string[];

  constructor(private dataService: DataService) {}

  ngOnInit() {
    this.items = this.dataService.getData();
  }
}

In this example, ItemListComponent depends on DataService to fetch the list of items. The service is injected into the component's constructor, and its getData() method is called in the ngOnInit() lifecycle hook.

5. Modules

Modules in Angular are used to organize the application into cohesive blocks of functionality. They group related components, directives, pipes, and services together. Angular applications typically have a root module (AppModule) and may have additional feature modules.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { GreetingComponent } from './greeting.component';
import { ItemListComponent } from './item-list.component';
import { DataService } from './data.service';

@NgModule({
  declarations: [AppComponent, GreetingComponent, ItemListComponent],
  imports: [BrowserModule],
  providers: [DataService],
  bootstrap: [AppComponent],
})
export class AppModule {}

Here, AppModule is the root module of the Angular application. It declares the AppComponent, GreetingComponent, and ItemListComponent, imports the BrowserModule, provides the DataService, and specifies the bootstrap component (AppComponent).

6. Templates and Data Binding

Templates in Angular combine HTML with Angular markup and directives to define the UI of a component. Data binding allows for the synchronization of data between the component class and its template.

<h1>{{ title }}</h1>
<button (click)="onClick()">Click Me</button>

In this template snippet, {{ title }} uses interpolation to display the value of the title property from the component class, while (click)="onClick()" sets up an event binding that calls the onClick() method when the button is clicked.

Conclusion

Mastering the core concepts of Angular is essential for developing robust and scalable web applications. Components, directives, services, dependency injection, modules, templates, and data binding are the building blocks that empower developers to create dynamic and interactive user experiences. By understanding these concepts and leveraging them effectively, developers can unleash the full potential of Angular for modern web development.

This article provides an in-depth exploration of Angular's core concepts, complete with illustrative examples to aid in understanding and application. By familiarizing yourself with these fundamental concepts, you'll be well-equipped to embark on your journey as an Angular developer.

what is the meaning of static in typescript classes?

Muhammad Tanveer — Mon, 01 Jan 2024 09:40:19 +0000

In TypeScript, the static keyword is used to define properties or methods that belong to the class itself rather than to instances of the class. Here are the key aspects of static in TypeScript:

Static Properties:
- When a property is declared as static in a class, it means that the property is associated with the class itself, not with instances of the class.
- Static properties are accessed using the class name, not an instance of the class.

   class MyClass {
       static myStaticProperty: number = 10;
   }

   console.log(MyClass.myStaticProperty); // Accessing static property

Static Methods:
- Similar to static properties, static methods are associated with the class rather than instances.
- They are called on the class itself, not on an instance of the class.

   class MathOperations {
       static add(x: number, y: number): number {
           return x + y;
       }
   }

   console.log(MathOperations.add(5, 3)); // Calling static method

Singleton Pattern:
- In TypeScript, the static keyword is often used in conjunction with the Singleton pattern.
- By declaring a static property that holds a single instance of the class, you ensure that only one instance exists throughout the application.

   class Singleton {
       private static instance: Singleton;

       private constructor() { }

       static getInstance(): Singleton {
           if (!this.instance) {
               this.instance = new Singleton();
           }
           return this.instance;
       }
   }

   const singletonInstance1 = Singleton.getInstance();
   const singletonInstance2 = Singleton.getInstance();

   console.log(singletonInstance1 === singletonInstance2); // true

No Access to Instance Members:
- Inside a static method, you cannot directly access instance members (properties or methods) of the class because the method is associated with the class, not a specific instance.

   class Example {
       static staticMethod() {
           // Can't access instance property directly
           // console.log(this.instanceProperty); // Error
       }

       instanceProperty: string = "Hello";
   }

In summary, static in TypeScript is used to define properties and methods that are associated with the class itself, rather than with instances of the class. It is commonly used for utility methods, constants, and for implementing patterns like the Singleton pattern.