Almost like the old days of fixed function pipelines. The example at the top seems a little contrived, I wonder why you would build a shader like that.
Unless I missed it somewhere, the two nodes that seem to be missing here are an if() node and a loop() node. I’m guessing a loop() node can be done on the JavaScript side for small loops - it’d be the same as loop unrolling. For big loops or loops with unknown bounds at compile time, it’s not clear if there’s a way with TSL. You can simulate if() behavior using the nodes provided, but you can’t avoid executing both sides of the if().
It’s been a long time since I wrote a three.js shader, so I’m not sure what the “old” example is doing. It looks like it might be a little dynamic code injection to convert from a typical GLSL shader to something three.js needs.
That’s not allowed in webgl, so I doubt TSL can make it work somehow.
Probably just for introductory ease. Although, admittedly, appears to give the impression of nerfed features, rather than easy.
Funny enough, the new work graph stuff in D3D12 is also configured in a similar way (by essentially building an AST-like tree of operations via API calls).
We really came around full circle ;)