Critique may sound negative, but it's not. I think the aproach has great potential, but there is a lot to do. What I'm attempting to do here is to offer a perspective on the current implementation noting some gaps in capabilities as well as some of the strengths of the library in hope that this will be helpful building out the future of graphics programming in Elm.
Getting type checking for shaders and never forgetting to set the correct uniform is great. However it is still easy to create a shader that crashes at runtime. This doesn't fit well with Elm's no runtime exceptions. The vast majority of these happen when actually compiling the shader at runtime. Hence it should be possible to detect these at (Elm) compile time (with the possible exception of pre-processor abuse... not sure about that).
For a lot of applications computing stuff on the GPU can be a huge boon. Wether that is multipass rendering or doing something graphics unrelated like machine learning, getting information is a huge feature. The immediate thing is to be able to render to texture.
WebGL2 brings a lot of desirable features and while current browser support is low, it is likely to improve dramatically within the year (the weak link being Safari that has shipped support in a technical preview, so quite likely the feature will ship with the next OS update).
Currently there is no way to compose shaders. One has to write an entire shader program in a single glsl block without any capability of having functions extracted to modules etc. Having a nice way to compose shader programs would allow libraries of shaders to exist, and allow us to abstract shader logic properly.
Debugging shaders can be very challenging and such having good test support can be vital. I think there are two kinds of tests that can be valuable using the features mentioned above:
- Using gpgpu and shader composition: one can test that inidividual glsl functions behave as expected.
- Snapshot testing: One can ensure that given stable parameters an entire WebGL program returns the same output. On failure some visual diffing would need to be done.
GLSL expressions aren't properly formatted :(
I've been using WebGL lately for data viz and cartography. I have never done any 3D or games, so there's probably more I'm not seeing. Feel free to comment and I can update this document.
According to "caniuse", the experimental and preview use of webGL2 in Safari is also combined with 77% of webgl2 tests failing. I was shocked when reading that. So chances may even be higher major browsers will support the proposed WebGPU standard earlier than Safari passing all WebGL2 tests.