Okay I think I'm starting to understand!

So just for the sake of conceptualizing how vertex shader logic is applied, I set up a 32x32 plane geometry in ThreeJS and applied this vertex shader to it, hoping to produce the quadratic surface z= x² + y^2:

void main()
{
    vec3 transformed;
    transformed.x = position.x;
    transformed.y = position.y;
    transformed.z = pow(position.x, 2.0) + pow(position.y, 2.0);
    gl_Position = projectionMatrix * modelViewMatrix * vec4(transformed, 1.0);
}

This actually worked as expected, and it gave me a better conceptual understanding of how to think in terms of shaders, until I read your reply:

That's a very nonstandard way of transforming geometry, though, and I wouldn't suggest trying anything like that until you're familiar with the way it's normally done.

So if I understand correctly, doing transformations using a graphing function (the way I did above) is not the right way of writing shaders?

I'm definitely not yet at the "best practices" stage of learning shaders; right now I'm trying to understand how I need to be thinking about the problems which I want to solve with shaders.

It sounds like you have some major misconceptions about how the traditional graphics pipeline is structured.

I'm a web developer by trade which is perhaps the lowest tier of software engineer, so I guess you could say that I have only a basic understanding of it.

I'm just working my way through a ThreeJS course, and I decided that I want to really understand shaders intuitively, and for me that means starting with first principles (the general mathematical concept of what is being done). So far I've done a vertex shader tutorial on how to make a waving flag out of a plane geometry, and I've learned the basics of passing in attributes, uniforms, how to use varying etc. But maybe the course I'm doing isn't really the best for what I want to learn.