Vertex vs fragment shader
The two halves of a shader: the vertex shader moves points, the fragment shader colors the fragments filling the gaps.
See it
What it is
Every draw runs two programs in sequence. The vertex shader runs once per corner point of your mesh and decides where that point lands on screen: transforms, wobble, wind sway, morphing, anything that moves geometry. Then the GPU fills in the triangles between those points and the fragment shader runs once per generated fragment, deciding its color: lighting, textures, gradients, glow, transparency. Fragment is not a synonym for pixel: overlapping triangles, overdraw, and multisampling can each make one screen pixel run the fragment stage several times over.
The practical rule is cost. A mesh might have 5,000 vertices but cover 800,000 pixels, so fragment work is often 100x more expensive. If a value only changes across the surface smoothly (a gradient by height, a fresnel term), compute it in the vertex shader and let the rasterizer interpolate it across the triangle for free via a varying.
Gotcha: interpolation is linear, so vertex-computed values look wrong on low-poly geometry. A per-vertex lighting term on a 6-sided cylinder gives you visible facets; the same math per fragment looks smooth. Also note the vertex shader cannot see its neighbors, and the fragment shader cannot move geometry, so displacement belongs in the first and antialiased edges belong in the second.
Ask AI for it
Write a three.js ShaderMaterial with both stages. In the vertex shader, displace position along the surface normal using a simplex noise function driven by uTime, and pass the world position plus the noise value to the fragment stage as varyings. In the fragment shader, mix two colors by that varying, add a fresnel rim term from the view direction, and output the result. Declare uTime and the two colors as uniforms, and keep the heavy math in the vertex stage where it runs fewer times.