DEV Community: TommyDee

Build a scroll-driven WebGL hero in 30 lines

TommyDee — Sat, 23 May 2026 15:24:31 +0000

Hero sections that respond to scroll are one of those features that look complicated and actually aren't, once you have the right pieces. Two images, a shader that morphs between them, scroll position drives the morph. That's it. The rest is plumbing.

This tutorial builds exactly that — a scroll-driven WebGL hero — in about 30 lines of JavaScript. Plain HTML, no framework, no build step. Drop it into a CodePen or a static HTML file and it works.

What we're building

Three behaviors, tied together:

As the user scrolls down into the hero section, image A morphs into image B.
While the hero is centered in the viewport, the morph holds on image B.
As the user scrolls down past the hero, image B morphs back to image A. That's the standard scroll-driven hero shape. Sites like Apple's product pages, Linear's marketing, and Vercel's case studies all use this pattern. The trick is the holding part — without it, the transition feels like it ends too fast and the user never sees the destination.

The dependencies

Two npm packages, both MIT, both tiny.

pnpm add @vysmo/scroll @vysmo/transitions

Combined, that's about 6 KB gzipped. Less than a logo SVG.

The HTML

A section, a canvas, two <img> elements that we'll use as transition sources, plus some content above and below to give the page something to scroll through:

<section style="height: 200vh; padding-top: 50vh;">
  <h2>Above the hero</h2>
  <p>Scroll down to see the effect.</p>
</section>

<section id="hero" style="height: 100vh; position: relative;">
  <canvas id="hero-canvas" style="width: 100%; height: 100%;"></canvas>
  <img id="img-a" src="/from.jpg" style="display: none;" />
  <img id="img-b" src="/to.jpg" style="display: none;" />
</section>

<section style="height: 200vh;">
  <h2>Below the hero</h2>
  <p>Keep scrolling.</p>
</section>

The two <img> elements are display: none because we're not rendering them as DOM — we're passing them to WebGL as texture sources. The browser still decodes them, which is what we need.

The JavaScript — 30 lines

import { Runner, crossZoom } from "@vysmo/transitions";
import { createScrollTransition, scrollPlateau } from "@vysmo/scroll";

const section = document.querySelector<HTMLElement>("#hero")!;
const canvas = document.querySelector<HTMLCanvasElement>("#hero-canvas")!;
const from = document.querySelector<HTMLImageElement>("#img-a")!;
const to = document.querySelector<HTMLImageElement>("#img-b")!;

// Wait for both images to decode before we use them as textures.
await Promise.all([from.decode(), to.decode()]);

// Match the canvas backing store to its CSS size so the shader renders sharp.
const dpr = Math.min(window.devicePixelRatio, 2);
canvas.width = canvas.clientWidth * dpr;
canvas.height = canvas.clientHeight * dpr;

// One WebGL2 runner per canvas. It owns the compiled programs and FBOs.
const runner = new Runner({ canvas });

// Bind scroll progress to the transition.
createScrollTransition({
  section,
  runner,
  transition: crossZoom,
  from,
  to,
  // Hold the "to" image while the section is 30%–70% through the viewport.
  ease: scrollPlateau(0.3, 0.7),
});

That's the whole thing. Let me walk through the parts that aren't obvious.

What `scrollPlateau` does

This is the part of the API I'd most like to spend a paragraph on, because it's the small idea that makes the whole pattern work.

Raw scroll progress is a 0 → 1 line as the section moves through the viewport. If you feed that directly into a transition, you get a morph that starts the moment the section enters and ends the moment it exits — which means the user only briefly sees the destination image as it flies past. Unsatisfying.

scrollPlateau(0.3, 0.7) reshapes that linear progress into a bathtub curve:

0.0 → 0.3 of scroll progress: transition plays 0 → 1
0.3 → 0.7 of scroll progress: transition stays at 1 (the "hold")
0.7 → 1.0 of scroll progress: transition plays 1 → 0 The result: the morph happens quickly as the section enters, the destination image gets to live on screen for the comfortable middle stretch, and the morph reverses on exit. Visually, the user feels like they "arrived" at something, instead of like something whisked past them.

You can change the plateau bounds to taste — scrollPlateau(0.1, 0.9) makes the entry and exit transitions very fast, scrollPlateau(0.4, 0.6) is slower and more deliberate.

Swap the transition for a totally different feel

The line transition: crossZoom is the one that defines the look. There are 60 built-in transitions, and switching is one identifier:

import { pageCurl } from "@vysmo/transitions";
// ...
createScrollTransition({ section, runner, transition: pageCurl, from, to, ease });

Now image A peels back like a page turn to reveal image B as you scroll. Same 30 lines of code, completely different aesthetic.

A few transitions worth trying for a hero:

crossZoom — the cinematic default; image A zooms in as it fades into B
pageCurl — editorial, like turning a magazine page
paintBleed — a paint-pour reveal, looks great for product launches
warpZoom — a chromatic warp; perfect for tech aesthetics
glassShatter — image A shatters into B; high-drama, use sparingly Each is a one-line change to the import and the transition prop. The catalog has all of them with live previews.

What's happening under the hood

In case the magic feels suspicious, here's what's actually running:

createScrollTransition registers your section with a shared IntersectionObserver and a single requestAnimationFrame loop (one rAF for all Vysmo scroll bindings on the page — that part matters for performance when you have multiple sections).
On every animation frame where the section is intersecting the viewport, it computes a raw 0 → 1 progress value from the section's bounding-box position.
It passes that value through the ease function (scrollPlateau in our case) to get a morphed progress.
It calls runner.render(transition, { from, to, progress }). The runner has the compiled WebGL2 shader cached, so this is just uniform updates and a draw call — sub-millisecond on a modern phone. No internal timers, no playback state, no "play" / "pause" / "reverse" — the renderer is idempotent. You give it a progress value, it draws that frame. Scroll up and the same code path runs the transition backwards. That's why the same library works equally well for rAF-driven animations, GSAP timelines, video exports, and scroll bindings.

Common gotchas

Image must be decoded first. If you skip the await Promise.all([from.decode(), to.decode()]) line, the first render might happen with one or both textures empty, and you'll see a flash of black. Always decode before passing to the Runner.

Canvas DPR. Without the canvas.width = canvas.clientWidth * dpr lines, the canvas backing store is whatever the browser defaults to (usually 300×150 px), which makes everything look like a pixelated mess. Match the backing store to the CSS size times device pixel ratio.

Don't run on iOS Low Power Mode. WebGL2 still works there but performance is throttled — the rAF callback may only fire 30 times per second instead of 60. Your transition will look choppy. Test on a real phone, not just your laptop with throttling disabled.

When you'd want more

This 30-line version covers a single hero. As your page gets more complex — multiple scroll-driven sections, scroll-driven text reveals layered on top, scroll-driven effects (a bloom that ramps as you enter, identity in the middle, fades on exit) — the same @vysmo/scroll package has primitives for those too:

createScrollEffect — drives a @vysmo/effects filter through the same three-zone envelope
createScrollProgress — raw 0 → 1 emitter you can wire to anything (opacity, transform, your own state)
sharedScrollObserver — for when you're building your own scroll-driven renderer and want to plug into the same single-rAF batching But you don't need any of that today. 30 lines, two images, one transition, one envelope. That's a shippable hero.

Try it

Full example, copy-pasteable, including the HTML scaffolding:

<!doctype html>
<html>
  <head><title>Vysmo Hero Demo</title></head>
  <body style="margin:0;font-family:system-ui;">
    <section style="height:200vh;padding-top:50vh;">
      <h2 style="text-align:center;">Scroll down</h2>
    </section>

    <section id="hero" style="height:100vh;position:relative;">
      <canvas id="hero-canvas" style="width:100%;height:100%;display:block;"></canvas>
      <img id="img-a" src="/from.jpg" style="display:none;" />
      <img id="img-b" src="/to.jpg" style="display:none;" />
    </section>

    <section style="height:200vh;">
      <h2 style="text-align:center;">Keep scrolling</h2>
    </section>

    <script type="module">
      import { Runner, crossZoom } from "https://esm.sh/@vysmo/transitions";
      import { createScrollTransition, scrollPlateau } from "https://esm.sh/@vysmo/scroll";

      const section = document.querySelector("#hero");
      const canvas = document.querySelector("#hero-canvas");
      const from = document.querySelector("#img-a");
      const to = document.querySelector("#img-b");

      await Promise.all([from.decode(), to.decode()]);

      const dpr = Math.min(window.devicePixelRatio, 2);
      canvas.width = canvas.clientWidth * dpr;
      canvas.height = canvas.clientHeight * dpr;

      const runner = new Runner({ canvas });
      createScrollTransition({
        section, runner,
        transition: crossZoom,
        from, to,
        ease: scrollPlateau(0.3, 0.7),
      });
    </script>
  </body>
</html>

Drop two images named from.jpg and to.jpg next to that file, open it in a browser, and you have a working scroll-driven WebGL hero.

The full catalog of transitions with live previews is at vysmo.com/transitions, and the scroll package docs are at vysmo.com/scroll. Source: github.com/vysmodev/vysmo. All MIT.

Meet @vysmo/effects — 30 WebGL2 filter effects in one render() call

TommyDee — Thu, 21 May 2026 16:18:10 +0000

There's a category of visual work the browser is genuinely good at and yet most projects either skip or reinvent: putting a filter on top of an image or a video. Blur a hero photo. Glow on hover. Halftone for the print-design aesthetic. ASCII for the terminal vibe. A scanline VHS pass for nostalgia.

You can do these in WebGL, but the gap between "I want a bloom on this image" and "working ping-pong framebuffer pipeline with HDR float targets" is wide enough that most people give up and reach for a CSS filter: blur(8px) and live with it.

@vysmo/effects is the tour I would have wanted when I first looked at this. 30 effects, one API, ~9 KB for the whole thing. Multi-pass pipelines are handled for you.

Four lines

import { Runner, blur } from "@vysmo/effects";

const runner = new Runner({ canvas });
runner.render(blur, { source: image, params: { radius: 12 } });

That's a real, shippable image filter — GPU-accelerated, runs at 60 fps on a phone. The source can be an HTMLImageElement, a canvas, a video, an ImageBitmap, an OffscreenCanvas, or ImageData. The Runner uploads it once and caches the compiled shader program between renders, so if you change radius and re-render, you skip compilation entirely.

Swap blur for any of 29 others and you get a totally different look from the same five lines:

runner.render(halftone, { source: image, params: { dotSize: 4 } });
runner.render(scanlines, { source: image, params: { intensity: 0.7 } });
runner.render(ascii, { source: image, params: { charSize: 8 } });
runner.render(oilPaint, { source: image, params: { brushSize: 6 } });
runner.render(swirl, { source: image, params: { angle: 1.2 } });

Each of those is one line and one new aesthetic. The catalog at vysmo.com/effects has all 30 with a live playground — pick one, drop your own image, tune the params.

Where this gets technically interesting: multi-pass HDR

Most filter effects are a single fragment shader pass: sample the image, do some math, write the output. Easy. The Runner draws once per render() call.

But some effects can't be done that way. Bloom is the canonical example. To make highlights glow believably, you need:

A bright-pass filter that isolates pixels above a luminance threshold
Several passes of a separable Gaussian blur on those highlights (horizontal, then vertical — multiple radii)
A composite pass that adds the blurred highlights back over the original Four passes, minimum. And to do it correctly, those intermediate textures need to be HDR floating-point (RGBA16F) — because once you've isolated highlights at 2× or 3× max brightness, an 8-bit-per-channel buffer clamps them to 1.0 and your bloom looks flat and ugly.

In @vysmo/effects, this is the API:

runner.render(bloom, {
  source: image,
  params: { intensity: 1.2, threshold: 0.7 },
});

Same shape as the blur example. One line. Internally the Runner allocates ping-pong RGBA16F framebuffers when the GPU supports them (every WebGL2 device built since 2017 does), runs the four-pass pipeline, and disposes the intermediate targets when you call runner.dispose(). You never see any of this.

The same architecture handles glow (similar multi-pass with a different bright-pass response curve), motion blur (multi-tap directional sampling), and datamosh (frame-history accumulation).

If you've ever tried to ship bloom from scratch with vanilla WebGL, you know how much code that hides.

The 30 effects, roughly grouped

Image cleanup and adjustment — blur, sharpen, color-grade, tint, dither, gradient-map. The everyday tools.

Print and editorial aesthetics — halftone, oil-paint, ascii. The looks designers reach for to make web feel like print.

Cinematic and lens — bloom, glow, tilt-shift, lens-distortion, motion-blur. The looks that make web feel like film.

Retro and degraded — scanlines, vhs, datamosh. The looks people use when nostalgia is the point.

Distortion and warp — wave, swirl. The looks for headers that want to feel alive.

Plus another dozen I'm not going to enumerate because that's what the catalog page is for.

A single-pass effect costs you a few hundred bytes in your bundle. A multi-pass effect costs you maybe a kilobyte. Import the two or three you actually use and your effects bundle is well under 2 KB.

Authoring your own

Same defineX pattern as transitions. Write a fragment shader that exports vec4 effect(vec2 uv), declare your params, done:

import { defineEffect, Runner } from "@vysmo/effects";

const sepia = defineEffect({
  name: "sepia",
  defaults: { strength: 0.8 },
  glsl: `
    uniform float uStrength;
    vec4 effect(vec2 uv) {
      vec4 src = getSource(uv);
      float gray = dot(src.rgb, vec3(0.299, 0.587, 0.114));
      vec3 sepia = vec3(gray * 1.2, gray * 1.0, gray * 0.8);
      return vec4(mix(src.rgb, sepia, uStrength), src.a);
    }
  `,
});

runner.render(sepia, { source: image, params: { strength: 0.6 } });

The Runner allocates FBOs as needed, manages uniforms, and dispatches passes — you write the math. The defaults object also drives type inference, so params is fully typed in your editor without you writing Effect<{ strength: number }> anywhere.

How it composes

Two patterns that show up constantly in real projects.

Effects on video. Pass a <video> element as source and re-render every frame:

const video = document.querySelector<HTMLVideoElement>("video")!;
video.play();

function frame() {
  runner.render(bloom, { source: video, params: { intensity: 0.8 } });
  requestAnimationFrame(frame);
}
frame();

Effects driven by interaction. Hook the params object up to a slider, scroll progress, or mouse position. The Runner caches the compiled program, so re-rendering with different params is essentially free:

slider.addEventListener("input", (e) => {
  runner.render(blur, {
    source: image,
    params: { radius: Number((e.target as HTMLInputElement).value) },
  });
});

That's an interactive blur control in eight lines of code, with a draw call that costs less than half a millisecond on a modern phone.

Try it

pnpm add @vysmo/effects

Then four lines:

import { Runner, bloom } from "@vysmo/effects";
const runner = new Runner({ canvas });
const image = document.querySelector("img")!;
await image.decode();
runner.render(bloom, { source: image });

Open vysmo.com/effects for the catalog and the playground where you can drop your own image and try every effect at every parameter combination. Source and issue tracker at github.com/vysmodev/vysmo.

All Vysmo libraries are MIT, zero dependency, free forever. There's no commercial tier and no telemetry.

Meet @vysmo/text - 243 text animation presets in 3 KB

TommyDee — Tue, 19 May 2026 21:50:11 +0000

The big text on a landing page deserves to arrive. The headline you spent two hours writing shouldn't just appear — it should choreograph itself into place, letter by letter, so the reader's eye lands on it and stays.

That's what @vysmo/text does. It's a new addition to the vysmo libraries — a tiny, tree-shakable, zero-dependency text animation library with 243 presets and one of the cleanest APIs I've used.

This is a tour.

Three lines

The simplest possible use:

import { animateText } from "@vysmo/text";

animateText(element, { preset: "enter/fade-up" });

That's a real, shippable hero animation. The library splits the text into grapheme-safe slices (more on that below), applies the preset's choreography, and starts playing on mount. No timeline setup, no .from() / .to() chains, no ref management.

If you'd rather have a different feel, change the preset name:

animateText(element, { preset: "enter/elastic-rise" });   // soft spring
animateText(element, { preset: "enter/bloom-scatter" });  // letters arrive from depth
animateText(element, { preset: "enter/whirl-scatter-curl" }); // dramatic, full-on
animateText(element, { preset: "enter/blur-in" });        // tasteful, agency-deck-ready

Same one line. 120 enter presets to choose from. The catalog at vysmo.com/text has all of them with a live playground — click one, type your text, see it.

243 presets, 3 KB

The headline number is real: 229 generated + 14 curated = 243 presets, in roughly 3 KB gzipped. That's a smaller bundle than most loading spinners.

The trick is tree-shaking. Each preset is its own ES module export. You import what you ship:

import { animateText, fadeUp } from "@vysmo/text";

animateText(element, { preset: fadeUp });  // pass the object, not the string

When you pass the preset by reference, only that preset's data lands in your bundle. The other 242 stay tree-shaken out. The string-name form ("enter/fade-up") pulls in a tiny registry — pick whichever ergonomics you prefer.

For a typical landing page using two or three presets, you ship under 2 KB total. For a kinetic-typography portfolio site that uses twenty different presets, you ship maybe 4 KB. Either way, less than a logo SVG.

The presets are split into three categories

Enter (120) — animations for text arriving. fade-up, elastic-rise, bloom-scatter, flip-up-spring, tunnel, plus 115 more. Tuned to feel deliberate, not gimmicky. Most run for ~600–900 ms.

Exit (92) — animations for text leaving. The conceptual mirror of enter, but harder to design well — exits need to feel intentional, not glitchy. fade-down, mist-out, collapse-burst, pinwheel-out. Most react well to being driven faster than their default duration.

Emphasis (31) — animations that loop or play on demand to draw attention. pulse, shake, wobble, coin-flip, spin. These are what you wire to a button click or a "10 items left" badge.

A preset is just data:

import { fadeUp } from "@vysmo/text";

console.log(fadeUp);
// {
//   name: "enter/fade-up",
//   split: "character",
//   stagger: 30,
//   animations: [
//     { prop: "opacity",    from: 0,  to: 1, duration: 500, ease: power2.out },
//     { prop: "translateY", from: 20, to: 0, duration: 500, ease: power2.out },
//   ],
// }

No classes. No inheritance. No registry magic. You can console.log a preset and read it. You can copy one and modify it. You can author your own with the exact same shape.

Two knobs that change everything

Every preset has a default — but the API lets you override any knob per call. Two of them, in particular, are the cheapest way to make the same preset feel completely different.

stagger is the milliseconds between consecutive slices starting. The default is 30 ms (energetic, fast). Bump it to 80 ms and the same preset feels slow and contemplative. Drop it to 10 ms and slices arrive almost together — more of a wash than a choreography.

animateText(element, { preset: "enter/fade-up", stagger: 80 }); // thoughtful
animateText(element, { preset: "enter/fade-up", stagger: 10 }); // urgent

staggerOrder is who gets staggered first. Default is "start" (left-to-right, like reading). But:

animateText(element, { preset: "enter/fade-up", staggerOrder: "end" });    // right-to-left
animateText(element, { preset: "enter/fade-up", staggerOrder: "center" }); // middle outward
animateText(element, { preset: "enter/fade-up", staggerOrder: "edges" }); // both ends inward
animateText(element, { preset: "enter/fade-up", staggerOrder: "random" }); // chaos mode

"center" is the secret weapon. Try it on a hero headline — letters bloom outward from the middle. It feels like the title is being projected rather than typed. Most libraries don't expose this and people don't realize how much they're missing.

Scrolling drives it for free

The handle that animateText returns has a .seek(progress) method that takes a value between 0 and 1 and snaps the animation to that point in its timeline. That's the only thing you need to drive a text animation from scroll position:

const handle = animateText(headline, {
  preset: "enter/bloom-scatter",
  autoPlay: false,
});

// In a scroll handler — pair with @vysmo/scroll, ScrollTrigger, or your own IntersectionObserver:
function onScroll(progress: number) {
  handle.seek(progress);
}

Cinematic word-by-word reveals tied to scroll position. Two lines. The reason this works cleanly is the library's single-master-clock architecture — every slice is animated against the same time origin, so seeking is coherent. That's worth a post on its own (it's coming).

The split is grapheme-safe

One detail that separates this library from most of its predecessors: the text splitting uses Intl.Segmenter. Which means it correctly handles emoji clusters, regional flags, combining marks, and connected scripts.

// Most libraries:
[..."👨‍👩‍👧"];  // ['👨','‍','👩','‍','👧']  — family emoji shattered into 5 broken pieces

// @vysmo/text:
splitText("👨‍👩‍👧", { mode: "character" }).slices.length;  // 1 — correct

If your animation has ever broken for users in India, Japan, the UAE, or anywhere with an emoji-rich messaging culture, this is why. The fix has been in browsers since 2020 and most libraries still don't use it. Vysmo does, by default.

Word-mode and line-mode use the same Segmenter, which means they also work correctly in Thai (no spaces between words), Japanese (mixed scripts), and Arabic (right-to-left). If you ship to a global audience by default — which, in 2026, is everyone — this matters.

React, too

There's a thin companion package, @vysmo/text-react, that wraps the runtime in a declarative component plus a useAnimateText hook:

import { AnimateText } from "@vysmo/text-react";

export function Hero() {
  return (
    <AnimateText as="h1" preset="enter/fade-up">
      Hello world
    </AnimateText>
  );
}

That's the whole component. Props pass through to the underlying runtime — preset, split, stagger, repeat, all of it.

Try it

pnpm add @vysmo/text

Then three lines:

import { animateText } from "@vysmo/text";
const h1 = document.querySelector("h1")!;
animateText(h1, { preset: "enter/bloom-scatter" });

Open vysmo.com/text for the live catalog and the studio that lets you tweak every knob. Source and issue tracker at github.com/vysmodev/vysmo.

Vysmo libraries are MIT, free, and zero-dependency — there's no commercial tier, no rate limit, no telemetry. Just one library doing one thing as cleanly as I could get it.

Migrating from gl-transitions to @vysmo/transitions: the diff that matters

TommyDee — Mon, 18 May 2026 21:53:33 +0000

If you've ever wanted a fancy crossfade between two images on the web, you've probably ended up at gl-transitions. It's been the de facto WebGL transition library for the better part of a decade — a community gallery of GLSL fragment shaders that mix two textures over a progress value from 0 to 1. It works. I shipped with it. You probably shipped with it.

But it's a WebGL1, untyped, class-based draw function bound to a context you manage by hand. In 2026 the rough edges show. So a few weeks ago I migrated a project to @vysmo/transitions — same conceptual model, modernized surface — and the diff is small enough to do in an afternoon and big enough to be worth writing down.

This isn't a "vysmo is better, install it" post. It's a "here's the diff, here's what changes, here's what doesn't" post. Decide for yourself.

The mental model is the same

Both libraries treat a transition as a GLSL fragment shader that samples two textures and a progress uniform, and writes a color. You drive progress from 0 to 1 over some duration and call render every frame.

That's it. If you understood gl-transitions, you understand vysmo. The differences are surface-level — until they aren't.

The five-line diff

Here's the same crossfade, in both libraries, side by side.

// Before — gl-transitions
import createTransition from "gl-transitions/lib/transition.js";
import GL from "gl-transitions/transitions/wind.js";

const gl = canvas.getContext("webgl");
const transition = createTransition(gl, GL);
transition.draw(progress, fromTex, toTex, w, h, { size: 0.2 });

// After — @vysmo/transitions
import { Runner, wind } from "@vysmo/transitions";

const runner = new Runner({ canvas });
runner.render(wind, { from, to, progress, params: { size: 0.2 } });

Visually similar. But notice what disappeared:

You no longer get the WebGL context yourself.
You no longer create textures by hand and pass them as fromTex / toTex — you pass HTMLImageElement (or canvas, video, ImageBitmap, OffscreenCanvas, ImageData) and the library uploads, caches, and reuses them.
The { size: 0.2 } is type-checked. Misspell it and your editor underlines it before you save.
createTransition(gl, GL) is gone. There's no per-shader instance to construct, dispose, or cache. The Runner owns the program cache. That's roughly 80% of the migration work right there.

What you gain (the bits that mattered for me)

Five things. In rough order of how often they showed up while I was porting.

1. TypeScript inference on every transition's params

The single biggest day-to-day improvement. In gl-transitions, params are an untyped object — you check the shader source to find out what's available and what's misspelled. In vysmo, every transition exports a typed defaults object and params is Partial<typeof transition.defaults>. Editor autocomplete tells you wind takes a size and direction, and what the value ranges are.

You never write Transition<{...}> by hand. Types are inferred from the data.

2. Tree-shaking per shader

gl-transitions ships ~80 shaders and most bundlers can't tree-shake them effectively because of how the registry imports them. You end up shipping every shader you don't use.

@vysmo/transitions exports each transition as a named export from the package root. Import paintBleed and crossZoom, and that's all that goes in your bundle. The whole library is ~5 KB gzipped if you imported everything — most apps ship 1–2 KB.

3. Sources aren't textures anymore

In gl-transitions you write your own texture upload pipeline. Decode an image, create a texture, set parameters, upload pixels, hand the texture to draw, manage its lifecycle. For a single transition this is fine. For a slideshow rotating through 12 images it gets tedious.

In vysmo, sources are anything the browser can draw: image, canvas, video, ImageBitmap, OffscreenCanvas, ImageData. The Runner has a texture cache that treats decoded images as immutable (uploaded once, reused) and re-uploads canvases/videos every frame because their pixels can change. You stop thinking about textures.

// Live video as the from-side. The Runner re-uploads its pixels per render() call.
const video = document.querySelector<HTMLVideoElement>("video")!;
video.play();

animate({
  from: 0, to: 1, duration: 1500,
  onUpdate: (p) => runner.render(crossZoom, {
    from: video,
    to: imgB,
    progress: p,
  }),
});

4. Mesh and multi-pass shaders work

This is the one that actually unlocked something for me. Effects like page-curl can't be done in a fragment shader — they need real geometry, silhouette, depth, self-occlusion. gl-transitions' shape (one fragment shader, one full-screen quad) rules them out. The community gallery has no working page-curl for this reason.

vysmo's Runner builds a vertex buffer and runs drawArraysInstanced for mesh transitions, and allocates ping-pong framebuffers for multi-pass shaders that need to read their previous output. Same render() call from your perspective — the difference is internal.

In practice this means pageCurl, polygonFlip, glassShatter, inkDiffuse, lenticularFlip, tileScatter all exist as built-ins. None of those are possible as pure fragment shaders.

5. Endpoint correctness is enforced

Every built-in is tested to produce pixel-pure from at progress=0 and pixel-pure to at progress=1. No near-misses, no one-frame flash at the end where blur is still half-applied. It sounds minor until you've shipped a transition that ends on a barely-visible artifact and your client emails about it on Tuesday.

If you author your own with defineTransition, the same invariant applies — and the docs lay out the three rules that make it work. Worth a separate post.

Porting a custom shader

If you wrote your own gl-transitions shader, the GLSL body usually ports as-is. Drop it into defineTransition:

import { defineTransition } from "@vysmo/transitions";

export const myWind = defineTransition({
  name: "my-wind",
  defaults: { size: 0.2 },
  glsl: `
    uniform float uSize;
    vec4 transition(vec2 uv) {
      float r = fract(sin(uv.y * 1000.0) * 1000.0);
      float m = 1.0 - smoothstep(-uSize, 0.0, uv.x - uProgress * (1.0 + uSize));
      return mix(getFromColor(uv), getToColor(uv), m * (0.3 + 0.7 * r));
    }
  `,
});

runner.render(myWind, { from, to, progress, params: { size: 0.3 } });

The renamings you'll do mechanically:

gl-transitions	@vysmo/transitions
`progress`	`uProgress`
`getFromColor`	`getFromColor` (same)
`getToColor`	`getToColor` (same)
`ratio`	derive from `uResolution`
custom uniform `size`	uniform `uSize`, key `size` in `defaults`

Naming conventions: transition names are kebab-case, export identifiers are camelCase, custom uniforms in GLSL are uPascalCase, mapped automatically from camelCase keys in defaults. So defaults.noiseStrength becomes uniform float uNoiseStrength; in your shader.

What you give up

Honest list, not a sales pitch.

WebGL1 support. Vysmo is WebGL2-only. Modern browsers all ship it (Safari 15+, iOS 15+, Firefox 51+, Chrome 56+), but if you support ancient mobile, you'll need a CSS opacity-crossfade fallback wrapped in a try/catch around the Runner constructor.
The community gallery model. gl-transitions has a huge community-contributed shader library on a single registry page. Vysmo ships 60 transitions, curated, with parameters and tested invariants — and a defineTransition API for your own. Different philosophy.
Maturity. gl-transitions has been around since 2016. Vysmo shipped this year. There's no Stack Overflow long-tail yet. If those tradeoffs aren't deal-breakers, the migration is roughly an afternoon for a single transition, a day for a slideshow.

The minimal port: do this

pnpm add @vysmo/transitions @vysmo/animations (drop @vysmo/animations if you have your own driver — GSAP, anime.js, raw rAF, scroll progress, anything that produces a 0→1 number works).
Replace your createTransition(gl, GLSHADER) calls with the corresponding named import: import { wind } from "@vysmo/transitions".
Replace new Runner({ canvas }) for the canvas; remove your manual gl = canvas.getContext("webgl") call.
Replace transition.draw(progress, fromTex, toTex, w, h, params) with runner.render(transition, { from, to, progress, params }). Pass your HTMLImageElement directly — drop the texture-creation code.
On unmount, call runner.dispose(). (gl-transitions leaks the context if you forget; vysmo also leaks it if you forget. The difference is vysmo gives you one method to call instead of context teardown + program deletion + texture cleanup.) That's it. Same shaders, same look, smaller bundle, types.

One philosophical note

The thing that sold me on the migration wasn't the type safety or the tree-shaking — those are table stakes. It was that runner.render() is idempotent. You pass the current progress on every frame and the library draws. There's no animation loop inside the library, no internal timer, no playback state to fight.

That means scroll progress drives a transition exactly the same way a requestAnimationFrame loop does, which is exactly the same way a video editor's timeline scrubber does, which is exactly the same way an export-to-MP4 frame iterator does. Same shader, four use cases, zero code changes. gl-transitions could technically work this way too — but its API hints toward a more imperative model and most people end up wrapping it in their own loop.

Idempotent render + plain-data transitions is a small architectural decision with surprisingly long reach. It's the part of the library I'd port to my own code even if I weren't using vysmo.

Vysmo libraries are MIT, free, all of them — github.com/vysmodev/vysmo. Docs, the full transition catalog with live parameter playgrounds, and a Next.js guide at vysmo.com.

I just open-sourced 13 MIT libraries for web visual effects

TommyDee — Sat, 16 May 2026 17:50:36 +0000

After months of work, today I shipped Vysmo — a set of MIT-licensed libraries for web visual computing. All 13 packages are now on npm under @vysmo.

What's in it

@vysmo/transitions — 60 WebGL2 transition shaders defined as plain data. Includes a mesh-based page-curl with drag-scrub mid-flip, polygon flip, and classic crossfades/wipes. Tree-shakable to the byte.
@vysmo/text — Multi-property choreographed text animation with 300+ presets. Grapheme-safe splitting via Intl.Segmenter works for emoji, Arabic, and Devanagari.
@vysmo/effects — WebGL filter primitives (blur, bloom, glow, vignette, chromatic aberration, color grading).
@vysmo/easings — 40+ named curves, parametric builders (spring, bezier, wiggle, rough), composition modifiers, CSS export, reduced-motion helpers.
@vysmo/scroll — scroll-driven primitives that compose with transitions and effects.
@vysmo/flipbook — drag-scrub page-flip component built on the page-curl shader.
@vysmo/slideshow — image slideshow with opt-in chrome, drives any of the 60 transitions.
@vysmo/animations — value-based tweening: animate(), spring(), timeline(), interpolate().
@vysmo/gl-core — shared WebGL2 plumbing.
Plus React wrappers: @vysmo/transitions-react, @vysmo/text-react, @vysmo/flipbook-react, @vysmo/slideshow-react.

Design principles

Zero runtime dependencies in every package.
SSR-safe at module load — enforced by a Node import test per package.
Headless-first — components are opt-in wrappers around a vanilla TS core. The same code drives canvas, image, and video sources.
Plain-data API for transitions, text, and effects so the same definition can drive DOM today and a canvas renderer later.

Quick example

Crossfade between two images with one of the 60 WebGL transitions:

import { Runner, paintBleed } from "@vysmo/transitions";
import { animate } from "@vysmo/animations";

const canvas = document.querySelector<HTMLCanvasElement>("canvas")!;
const runner = new Runner({ canvas });

const fromImg = new Image();
const toImg = new Image();
fromImg.src = "/photo-a.jpg";
toImg.src = "/photo-b.jpg";
await Promise.all([fromImg.decode(), toImg.decode()]);

animate({
  from: 0,
  to: 1,
  duration: 1200,
  onUpdate: (p) => runner.render(paintBleed, {
    from: fromImg,
    to: toImg,
    progress: p,
  }),
});

The transition is just plain data describing how to interpolate between two textures. The Runner handles WebGL plumbing.

DEV Community: TommyDee

Build a scroll-driven WebGL hero in 30 lines

What we're building

The dependencies

The HTML

The JavaScript — 30 lines

What scrollPlateau does

Swap the transition for a totally different feel

What's happening under the hood

Common gotchas

When you'd want more

Try it

Meet @vysmo/effects — 30 WebGL2 filter effects in one render() call

Four lines

Where this gets technically interesting: multi-pass HDR

The 30 effects, roughly grouped

Authoring your own

How it composes

Try it

Meet @vysmo/text - 243 text animation presets in 3 KB

Three lines

243 presets, 3 KB

The presets are split into three categories

Two knobs that change everything

Scrolling drives it for free

The split is grapheme-safe

React, too

Try it

Migrating from gl-transitions to @vysmo/transitions: the diff that matters

The mental model is the same

The five-line diff

What you gain (the bits that mattered for me)

1. TypeScript inference on every transition's params

2. Tree-shaking per shader

3. Sources aren't textures anymore

4. Mesh and multi-pass shaders work

5. Endpoint correctness is enforced

Porting a custom shader

What you give up

The minimal port: do this

One philosophical note

I just open-sourced 13 MIT libraries for web visual effects

What's in it

Design principles

Quick example

Links

What `scrollPlateau` does