Random comment. I've monitored the discussions of WHLSL/WSL vs SPIR-V and I can't decide which side I'm on.
I started in the SPIR-V camp. I liked the idea that WebGPU would just get "shader assembly language" and that would let a 1000 other higher level languages blossom. I also liked the idea that injesting assembly seemed easier and less code than injesting a higher level language.
But, Apple had their original WHLSL post (https://webkit.org/blog/8482/web-high-level-shading-language...) and I liked some of their arguments for a text based language. I like the idea that I can just make snippet/jsfiddle/codepen and don't need a entire tool chain nor any 3rd party libraies just to get something working. I have 100s of standalone WebGL samples that have next to zero external code. I'd like to do the same with WebGPU but if it's SPIR-V based that will be impossible.
I also agreed that AFAICT SPIR-V being more assembly language like is not really a help. To validate it still requires a bunch of work, understanding it as a whole (building up an AST?) and checking everything so it's not clear to me there's a win there. The SPIR-V came does list some valid points here in relation to validation
https://github.com/gpuweb/gpuweb/issues/44
It's also been pointed out that SPIR-V is not a small format. Suggestions have been made that if you care about download size you'd send some other format that is smaller + a library to decompress/compile that format into SPIR-V. That sounded less interesting to me as again I need now both an offline toolset and a library to use its results.
I don't remember why but at some point I gravitated back toward the SPIR-V camp but when I went over the arguments it turned out to be mostly a tie.
I feel like if someone wrote a WSL or GLSL to SPIR-V compiler that was very small (50k to 100k compressed JS), ideally in JavaScript not WebAssembly, that might help decide the issue? Unfortunately AFAIK none of the devs involved with WebGPU are JS programmers so they do things like re-compile ANGLE's GLSL compiler via Emscripten as a solution which turns into a large bloated library with multiple parts.
I hate the idea that I won't be able to create small WebGPU demos without large external libraries or without finding places to host binary spirv files. A small library might push me in the SPIR-V camp. Without that I think I lean to the WSL camp.
I think the SPIR-V camp would argue that small samples don't matter. What matters is AAA games and AAA apps like Google Maps and those teams don't care if they have to use large offline toolsets. They'd also argue there's 2 or 3 orders of magnitude more devs using a large library like three.js than using low-level WebGL so the fact that without a large library the experience sucks is irrelevant. So again, I don't know which direction is better.