Shaders, Explained for Web Developers

Every draw runs two programs, and they have completely different jobs.

The vertex shader runs once per vertex — per corner of every triangle. Its one required job is to output where that vertex ends up on screen. A cube has 8 corners (24 with split normals), so this runs a handful of times. On a detailed character mesh, tens of thousands.

The fragment shader runs once per fragment — roughly, per pixel the triangle covers. Its one required job is to output a colour. This is where lighting, texturing, and every interesting visual effect lives.

The count difference between them is the single most important performance fact in graphics. A full-screen quad on a 1440p display at 2× device pixel ratio is around fifteen million fragment shader invocations per frame. The vertex shader for that same quad ran four times.

So the first optimisation instinct to build is: can this move to the vertex shader? Anything that varies smoothly across a surface — a gradient, a fade based on distance, a value derived only from position — can usually be computed per-vertex and interpolated across the triangle for free. The rasteriser interpolates between vertices at no cost. Computing the same thing per-pixel means doing the work millions of times instead of thousands.

Four properties, and every confusing rule about shaders is downstream of one of them.

1. Your code runs millions of times, in parallel. You are not writing a program that draws a shape. You are writing the answer to a question the GPU asks about one pixel, and it asks a few million of those simultaneously. Stop thinking "draw a circle" and start thinking "given this pixel's coordinate, is it inside the circle?" That reframing is most of the battle.

2. Each invocation is blind. A fragment shader cannot see the pixel next to it, cannot see the previous frame, and cannot accumulate anything into a shared variable. There is no for each pixel loop you are inside of. Effects that genuinely need neighbouring pixels — blur, edge detection — are done by rendering to a texture first and sampling that texture in a second pass.

3. Branching is not free. A GPU executes threads in lockstep groups. If some pixels in a group take the if and others take the else, the hardware runs both branches for the whole group and discards the results that do not apply. A branch on something that varies per-pixel costs you both sides. This is why shader code leans on mix(), step() and smoothstep() instead of if: they are branchless arithmetic that produces the same result.

// Costs both paths when the condition varies across the group
if (dist < 0.5) { color = red; } else { color = blue; }

// Branchless: one arithmetic path, always
color = mix(red, blue, step(0.5, dist));

4. There is no state between frames. Every frame starts from nothing. Anything that needs to persist — a simulation, a trail, an accumulation — has to be stored in a texture or buffer you read next frame. That constraint is exactly what compute shaders in WebGPU exist to make bearable.

More shader bugs come from being in the wrong coordinate space than from any other cause. There are five that matter, and the vertex shader's job is walking a position through them.

Space	What it means
Model / local	Coordinates as authored, relative to the object's own origin
World	After the object's position, rotation and scale are applied
View	Relative to the camera — camera at the origin, looking down −Z
Clip	After the projection matrix; what the vertex shader must output
Screen	Pixels, after the GPU divides by w and maps to the viewport

The classic vertex shader line is just that walk, right to left:

gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);

Two rules worth memorising, because they cause the two most common visual bugs:

Lighting must happen in a consistent space. Mixing a world-space light direction with a view-space normal produces lighting that swims as the camera moves — a bug that looks like a lighting problem and is actually a space problem.

Normals do not transform like positions. Under non-uniform scale, transforming a normal by the model matrix skews it and your lighting goes wrong. Normals need the inverse transpose — which is what Three.js's normalMatrix is. If your lighting breaks only on scaled objects, this is why.

Then there is UV space: the 2D coordinates, conventionally 0–1, that map a texture onto a surface. Most shader effects are ultimately arithmetic on UVs. Distort the UV before sampling and you get warping, ripples, and most screen-space effects.

Here is a complete, minimal fragment shader. It is worth reading line by line, because the shape is universal.

varying vec2 vUv;         // interpolated from the vertex shader
uniform float uTime;      // same for every pixel, set from JavaScript
uniform vec3 uColor;

void main() {
  // Distance from this pixel to the centre of the surface
  float dist = distance(vUv, vec2(0.5));

  // A soft circle: 1 inside, 0 outside, smooth at the boundary
  float circle = 1.0 - smoothstep(0.3, 0.32, dist);

  // Animate by pulsing the radius over time
  circle *= 0.75 + 0.25 * sin(uTime * 2.0);

  gl_FragColor = vec4(uColor * circle, 1.0);
}

Three kinds of input, and knowing which is which is most of reading shader code:

• uniform — a value from JavaScript, identical for every invocation this draw. Time, a colour, a texture, the camera position.
• varying (called in/out in newer GLSL) — a value the vertex shader wrote, interpolated across the triangle by the rasteriser. Different for every pixel, free to produce.
• attribute — per-vertex data from the geometry buffers. Vertex shader only.

And note what the code does not do: there is no loop over pixels, and no branch. smoothstep draws the circle's edge, and a multiply animates it. That is idiomatic shader code — arithmetic on coordinates, not control flow.

Custom shaders are a cost: they are harder to write, harder to debug, harder to hand over, and they bypass the material system's features unless you re-implement them. Worth it in these cases, and often not otherwise.

Effects with no material equivalent. Dissolves, holograms, energy fields, stylised outlines, water, terrain blending, anything non-photorealistic. A standard PBR material has no path to these.

Animation the GPU should own. Moving thousands of vertices — grass, cloth ripple, waves, morphing — in a vertex shader rather than updating positions in JavaScript. This is often the difference between fifteen and sixty frames per second, because the CPU stops touching per-vertex data at all.

Weight, when weight matters. A generated shader costs kilobytes where an equivalent set of textures costs megabytes. Procedural noise, gradients and patterns download as almost nothing. That is the argument the hero on this site's interactive 3D page makes.

Data-driven visuals. Colouring a hundred thousand instances by a value, in one draw call, with no CPU involvement.

Where they do not pay off: matching a photographed material, standard lighting on a standard object, or anything the built-in materials already do. Reaching for a custom shader to reproduce MeshStandardMaterial badly is a common and expensive mistake.

There are now three answers to "which language do I write this in", and the choice matters more than it used to.

GLSL is what WebGL runs. Every tutorial, every Shadertoy example, every Book of Shaders chapter is GLSL. It is the lingua franca, and it is what you will be reading regardless of what you write.

WGSL is what WebGPU runs. Newer, stricter, Rust-flavoured, no preprocessor. Better designed, with far less existing material to learn from.

TSL — the Three.js Shading Language — is neither. You describe the shader as a graph of nodes in JavaScript, and Three.js compiles it to WGSL or GLSL depending on which backend is running. One source, both APIs.

For work that ships to real users, TSL is what I now reach for, because it makes the WebGPU-or-WebGL question a runtime detail rather than a commitment. For learning, GLSL is still the better first language — the material available is vastly deeper, and the concepts are identical either way.

The practical route is to learn the ideas in GLSL and then move production work to TSL. If you already have GLSL you want to bring across, the GLSL to TSL converter on this site does the mechanical part.

The failure mode is reading shader tutorials and never writing one. Shader code is not learnable by reading, because the feedback loop — change a number, see the picture change — is the entire teaching mechanism.

What works, roughly in order:

1. Draw shapes with maths, in 2D, before touching 3D. A circle, a rectangle, a grid, a ring. This teaches the "answer a question about one pixel" reframing better than anything else, and it is where step and smoothstep stop being mysterious.
2. Then noise. Value noise, then gradient noise, then fractal noise (several octaves summed). Almost every organic-looking shader effect is noise plus a colour ramp. This is the highest-leverage single topic.
3. Then move to 3D, where the same tools apply to surfaces instead of a flat plane.
4. Change one thing at a time and look. Multiply a UV by 5. Add time to it. Feed the result into a colour. The intuition comes from watching what each change does, not from understanding it in advance.

Read other people's shaders constantly — Shadertoy is unmatched for this, and much of it is GLSL you can paste and modify.

When you want structure rather than self-direction, the TSL courses on this site take the node-based route from first principles, and the Living Planet course builds one shader up in small steps, which is the format I would have wanted when I was learning this.