Move to modern JS

[Valerioageno]

Hi guys, here Valerio from twitter.
Nice repo.
I've just moved the project to a modern JS implementation using the OOP approach.
In this way we can hide to the developer useless internal method for he/she, have a more clean repository and use shader with original glsl file format. Now the repo is bundled using rollup and at each build it creates a module file (to publish on npm) a simple js file for browser/cdn purposes and a zip file.
The global file is a little heavier but thanks to rollup is tree shakable so if I just need the cube (or any other non necessary model or plugin) the other will be removed at build time!
Other thing is that rollup minified the program so we can use more verbose params and variable names (it's been very hard debug the program with this really short names).

The API is little changed so; now for call the program we need: const w = new W.Renderer(props) where, currently, props are: {debug: boolean, canvas: HTMLCanvasElement}. Then we can call the same method from the w constant like w.light(props).

Call the built-in models now is w.add({modelName: string, object: obj, settings: set}) where object is W.Cube, W.Spere and so on and the settings are the usual group, name, size, position, rotation, background, texture, smooth...

If I may suggest some advice the next things to do are:

• deploy on npm
• deploy the CDN in a real cdn service like https://github.com/jsdelivr/jsdelivr
• create a CI pipeline (let me know if I can help on this)

Once the deployments are done we can also remove the dist/ folder from the repo.

[xem]

Hi Valerio, and thanks for this hard work, as it gives me a new point of view on "modern JS", of which I'm not an expert yet.

I have a few questions:

• you talk about an "original glsl file format", is this format official? Is there a source that affirms this? When I learned WebGL in 2020, I only found sources saying that the GLSL code could be put in text files called whatever or in JS strings...
• I understand the advantage to have this project available on NPM and on a CDN (and I'll probably do it asap, thanks for the idea), though I'm not sure about the importance of hiding the internal methods to the users, nor about making the code OOP. It seems to me that it brings very few advantages compared to the many extra kilobytes it adds to the JS file, but as I said, I'm not an expert myself and I'd be happy to discuss/learn more about this.
• As you said, the result (JS/Zip) is a bit heavier like that, and that's probably the main problem I have with it. I developed W with size-constrained game jams as the main goal (ex: js13kgames.com) and unfortunately, in that context, more kilobytes of WebGL framework equals less kilobytes to make the rest of the game
• Sorry for the short variable/params names, I'm still working on improving them, as the minifier I use (Terser) also renames them automatically. There should be very few of them left now.

Again, thanks for your effort. I can't merge it on the main branch as-is (mostly because of the extra kilobytes), though I can add a link to your repo for people looking for an OOP approach. Other forks have started adding hoooks for other languages/systems, I will add links to them too :)

Cheers and happy new year,
Xem @stasm

[Valerioageno]

Hei Xem,
actually glsl could correctly be putted as a literal string inside the JS file as you did but is still a real c-like language with its own format in fact is possible import it as script or as plain file.
The more advantage here is the use of glslify which allow the use of a more "modern" glsl with high level functionality like imports.
Regard the class style I thought about it since is more reusable and clean for a project then a simple object. Even if the purpose of this library is the lightweight size is not ready alone to work as engine for a game since lack to many basic feature like a "raycaster" (for dynamically interact with objects with mouse or touch), canvas/camera resize (I think it is for multi screen size availability) and other (I'm not really a game developer maybe I'm wrong).
Also interact directly with object is not a best practice, if you still prefer the object you should check the proxy pattern or the prototype pattern as well (still if the project grows).

For these reasons I thought that the project could fit better like a tree shakable module than a black or white minified file to download.

Cheers and happy new year too,
Valerio

[Lukenickerson]

FWIW, I think the "micro" aspect of this library is the critical feature, so I don't think there should be any changes that increase the final zipped file by more than a few bytes.