Why TypeShade
Two copies of every shader
A shader that has to run on WebGL2 and on WebGPU exists twice. The two languages disagree about types, entry points, resource binding and precision, so the second copy is a rewrite. A fix that lands in one copy and misses the other only shows up on the machines that take the other path, and a reviewer has to read two dialects to decide whether they still mean the same thing.
The move to WebGPU
The web is in the middle of one such move. The MapLibre graphics modernization roadmap, the deck.gl WebGPU guide and the PixiJS v8 migration guide each describe a WebGPU path arriving beside an existing WebGL one, so a custom layer written as GLSL will need a WGSL copy.
What the survey says
In the Khronos 2026 Real-Time Shading Ecosystem Survey, 64% of the 400+ shader developers surveyed adapt shaders across platforms, APIs or tools, and nearly 10% describe it as a significant engineering cost or one of their largest.
What TypeShade does
TypeShade keeps one source. The module is typed TypeScript, so a misspelt field or a wrong-typed return is caught in the editor; one intermediate representation emits both languages; and the same module compiles to a CPU function in double precision, so what a backend produces can be checked against a reference computed from the same source. The checks page says what runs on every push.
What it does not do
TypeShade has no renderer and no scene graph. It returns strings and reflection metadata; creating pipelines, binding resources and issuing draws stay with the host. SPIR-V, MSL and HLSL come out of naga or Tint, fed the WGSL, because every native host already reaches WGSL through Dawn or wgpu.