I am still scratching my head over why not just use GLSL instead of creating WGSL as a new shader language? I even saw references to: https://xkcd.com/927/ in the propsed FAQ 😆

All browser already takes GLSL input (for WebGL) so would assume some part of parser could be re-used.
All major engines (unity, unreal, godot) already produce GLSL output (for WebGL builds)
All WebGL engines/frameworks (three.js, Babylon.js, CesiumJS) already use GLSL
Also apps would need to ship a GLSL shader compiler, for those dynamic generated shaders that cannot be handled build time. This will add substantially to bundle size (shaderc is ~3MB, think glslang is ~1MB, compare to typical webgl engine size of a few 100K) and add extra processing: shaders now have to go: GLSL -> WGSL -> browser -> SPIR-V/DXIL/MSL.

Alternative would be to rewrite all shaders in WGSL, but on top of having to port API to WebGPU, I suspect for many smaller teams, this just won't be feasible. We e.g. have ~2.2K lines of GLSL code, that have been hand tweaked over almost 10 years - porting that to WGSL is not a trivial task for us.

I may be missing something essential here, but really don't understand the reasoning 😟

(Mostly copied from #593 (comment) - to be handled here as a separate issue.)

I can see others have similar concerns (#593 (comment)).

UPDATE: I think what is important is to have the motivation for not choosing GLSL well document and easily found, as I imagine other developers from a WebGL background will have similar concerns.

Also having a good (emerging) story on tooling for using GLSL with WebGPU, (e.g. optimized glslang with WGSL output, or other small and fast compiler) will help a lot :)
Also I assume the issue blocking from using SPIR-V (Apple vs. Khronos) doesn't apply to GLSL?