One of the most popular libraries for GPGPU in the javascript eco-system is:
https://github.com/gpujs/gpu.js/
It works by taking a javascript function and compiles it to a WGSL shader at runtime.
It does so quite well, despite javascript not having any types.
Typescript of course would be a better foundation for compiling into shader format,
but AssemblyScript would be even better, since it is even more refined in terms of types and constraints.
Hence one could leverage the existing infrastructure to offer compile targets into WebGL shader and WebGPU shader formats.
Compiling could be done statically via cli utilities etc.
One would just have to include type definitions that match the types available in the respective shader environments.
For Math library stuff, I believe gpu.js should serve as a great foundation for translating calls etc.
I believe this proposal would increase the target group for this library substantially, since it targets web developers who are familiar with typescript etc, but don't want to use static languages directly, hence it seems like an organic extension of its founding principles.
One of the most popular libraries for GPGPU in the javascript eco-system is:
https://github.com/gpujs/gpu.js/
It works by taking a javascript function and compiles it to a WGSL shader at runtime.
It does so quite well, despite javascript not having any types.
Typescript of course would be a better foundation for compiling into shader format,
but AssemblyScript would be even better, since it is even more refined in terms of types and constraints.
Hence one could leverage the existing infrastructure to offer compile targets into WebGL shader and WebGPU shader formats.
Compiling could be done statically via cli utilities etc.
One would just have to include type definitions that match the types available in the respective shader environments.
For Math library stuff, I believe gpu.js should serve as a great foundation for translating calls etc.
I believe this proposal would increase the target group for this library substantially, since it targets web developers who are familiar with typescript etc, but don't want to use static languages directly, hence it seems like an organic extension of its founding principles.