(This is a simplified explanation for those with no graphics programming experience to get some basic understanding of what is happening on this site)
Everything that you can see on your screen currently was the output of a graphics pipeline. The graphics pipeline is a fixed series of functions that run on the GPU, taking geometry and texture data as input and using that to draw images on the screen.
Many of the functions in the graphics pipeline are baked into the GPU and cannot be changed. But a few of them are programmable and act as a kind of plugin system for the graphics pipeline. These programmable functions are called shaders, and they are written in GLSL (there are other shading languages, but this is what WebGL requires). The two most common types are vertex shaders and fragment shaders, but you only need to understand fragment shaders for this site.
A fragment shader is a function that takes a pixel position (and other arbitrary data that you pass it) and returns a color. On this site, you write a fragment shader using the code editor (right side) and then it is executed for every pixel on the canvas (left side), producing the final image.
You might be wondering why all of this complexity is necessary to draw pixels on the screen. You could imagine creating a JavaScript function that iterates through each pixel and writes a color to the screen. But if you consider that there are over 2 million pixels on a 1920x1080 display, and that you need to write to all of them in under 17 milliseconds to achieve 60 frames per second, the answer may become clearer. GPUs are optimized for doing many similar operations in parallel in a way that CPUs are not.
This is just scratching the surface of the vast field of computer graphics, but it should get you started on understanding the fragment shader effects on this site. If you'd like to learn more about fragment shader programming specifically, I'd recommend The Book of Shaders.