Post

📣 call for feedback! I'm having second thoughts about the naming of the functions in my #webGL library. TL;DR: is it ok to have functions starting with "use" in a vanilla JS library ? explanation in thread 🧵

I like the hook-style naming with "use" because the functions actually behave like hooks (output destructuring, re-render when updated etc), but I wonder if they could be confused with "real" hooks or composables in a react or vue codebase. I'm not sure if it would be a big issue though.

Also, I don't know what other names to use: I can't remove the "use" because the functions would have the name of the object they return. e.g, "const compositor = compositor(...)" is not possible. And I don't want to prefix "createXXX" on all functions. So yeah, I would appreciate some feedback!

I use vanilla JS signals a lot, and I think they behave much like your hooks. I use them like this: “thing = Thing.get()”. When I write something that’s not a signal it’s usually like “thing = getThing()”. Feels quite consistent and nice.

Ok I understand, in my case I think it would be something like « createRenderPass(…) », but it seems a bit verbose to me. I also thought about a « gl » prefix, like glRenderPass(). It’s shorter and allow to separate WebGL related stuff from JS utils. I think I like this one. What do you think ?

Maybe! Might be annoying in the future if you want to write similar functions for WebGPU or something else and need to come up with a replacement for the “gl” prefix? I guess there are not many neutral options that are short. use, get, do….

Good point, writing similar functions in webGPU has crossed my mind. But since they are low level and the webGPU API is quite different, I don’t think the same functions will work for both. So either it will be another lib, or I use 2 prefixes (glCanvas / gpuCanvas), which seems consistent

The functions in your example are pretty high-level (fullscreen quads, compositor chains…). They’d likely have direct equivalents in a WebGPU-based app 🤷‍♀️

Indeed, but their arguments are more low-level and close to the webgl api (at least currently), and: - in webGPU we can write fragment and vertex shaders in one string - many things become a kind of « buffer » - compute shaders, pipelines, bind groups etc don’t exist in webgl 1/3

Currently the API is designed as a light layer on top of webgl, which makes it difficult to reuse with webGPU. The idea of sharing functions for both apis is interesting but I’m not sure how to handle their differences. I would like to keep it low-level, the focus is on writing shaders 2/3