For anyone interested in playing around with SDFs, my friend and I made this open source library to make working with them more efficient, and you can write shaders using javascript https://github.com/shader-park/shader-park-core
GLSL is great! But it is very limited in many aspects. Js enables us to create a more ergonomic APIs for SDFs similar to processing/p5. You can easily mix the glsl and js code, and it also allows you to directly implement transformations on SDF functions, like revolving or extruding a 2D SDF into a 3D one with a transformation function:
The first question was why anyone would write a shader in javascript, then it turned out it wasn't actually shaders written in javascript. Now you're telling me you can again, but the question is still why.
The first example was a js shader too but because it also included glsl it could have been easy to miss that. So the second example just emphasizes that better. Regarding why, see my first answer or feel free to browse the thousands of other examples on the site!
Why do you keep calling these shaders? Javascript isn't running on the GPU and it isn't doing any rendering. If making SDF data is called a shader, all scene setup is not and geometry creation would be the same.
Again, just passing around a javascript function doesn't mean it's a shader. Javascript isn't running the GPU and javascript isn't doing any rendering.
Shaderpark does a bit more than "pass around" javascript functions, it transpiles them to glsl. Believe it or not, web browsers themselves only transpile webgl shaders to other high level shader languages: hlsl on windows, msl on macos/ios, and glsl or sprir-v on linux. The os then compiles these to bytecode, and the driver finally compiles them to machine code which is sent to the GPU. So a webgl glsl shader isn't "running the gpu" or "doing rendering" any more than a js shader. They're both just high level languages at the top of a compilation chain ultimately targeting the GPU.
This comes back to the original question, why compile javascript to glsl? I don't think you ever answered that. There are severe limitations in shading languages that javascript doesn't have and shading languages are made to deal with. Where is the benefit?
Have another look at the first example I shared. One major limitation of glsl is a lack of functional programming. In that example, we pass functions to other functions, and iterate over arrays of functions, neither of which are possible in glsl. This is used to implement generic transformations of SDFs. If you did the same with just glsl it would be much longer, harder to read, and there would be duplicated code.
You can even use recursion (with limitations of course)!
At the same time, many more people know javascript than shader languages, so this makes it easier for beginners to get their hands dirty and can be a gateway to gpu programming.
So there are benefits for both novices and advanced users! There are pitfalls to this approach too of course and it certainly isn't a replacement for glsl, but the purpose is simply to explore new possibilities :)
I've been watching a playlist which is making shader programming click for me: https://www.youtube.com/watch?v=u5HAYVHsasc&list=PLGmrMu-Iwb... "The Art of Code" channel, "ShaderToy Tutorials" playlist. I think if you know some geometry/trigonometry, once you wrap your head around writing a function that maps any pixel to a color (and how you add or multiply colors, and think in vectors), it starts to get fun.
If you want a recommendation, I'd start with videos 30 and 37 in the playlist for a cool demo, then the 1st 4 videos (note: the video quality improves in later videos), then 10 and 11, then RayMarching starts in 22-24 and 29. (Many other videos in that channel are great for shader programming techniques, too.)
