@Oscar thanks for writing it down!
I totally get your point about performance, however I would like to talk separately about WebGL and projects, that require a lot of linear algebraic computations 60 frames per second (like elm-physics).
WebGL in Elm has a certain model with its own limitations, but it is still possible to make graphics performant by leveraging the fact that meshes are cached on GPU, and the only changing data is uniforms that parametrize the scene. This is already documented in the readme.
It is a different problem if something that we want to animate requires a lot of linear algebraic computations. But in the end we may or may not choose to render the result with WebGL. That’s why I think it would make sense to focus on the performance of linear-algebra separately.
While linear types are above my level of competence, I have already suggested the solution number 2 in my second post about elm-physics. After that post I spent some time on benchmarking record based linear algebra against the one based on typed arrays in this project. Unfortunately these microbenchmarks showed weird results that I could not trust (things just cannot get 1000x faster). That’s why I think it would be better to have more projects like elm-physics that would push linear-algebra to its limits, and thus could be used for such benchmarks.
Your main point is that it doesn’t make sense to use WebGL in Elm because it would perform bad, my point is that we should try and implement things regardless. This way we can get real performance numbers that would help to shape the limits or convince that certain improvements are necessary. Otherwise this is a chicken and egg kind of problem.