shipyard VS awsm-web

With game matching the binary name used in Cargo.toml, above. The code we use is provided as an example of using the Shipyard Rust ECS. Paste the main.rs square_eater code from the repo into src/bin/main.rs in your project.

I also initially followed the amazing bracket-lib tutorial, but was not satisfied with specs. Tried legion, but it seems kind of abandonned too. I choose to use shipyard in my project and I am pretty satisfied with it until now. I feel like it's a great compromise between usability and effectiveness, plus there is relatively up-to-date documentation. Maybe can you give it a try ?Shipyard

Shipyard (Rust)

It's not that it's incompatible, it's that when the ECS is the primary tool for organization, a DOM tree (or scenegraph) is merely one way of iterating over the entities - not the way.

This provides tons of benefits, so for example you can also decide to iterate over the entites by shader program and gain significant speedups for graphics processing, or maintain components that roughly sort them by their position in world space for physics and culling or lighting, etc.

To add to the sibling comment, there's another wonderful Rust ECS called shipyard[0] and I helped write a scenegraph for it (which I really need to update, one of these days)[1]

[0] https://github.com/leudz/shipyard

Just as a final thing here, are, a, bunch, of, links for shipyard's tuple impls to show how its not an uncommon thing to need to do when writing an ECS :)

I wrote an opinionated WebGL wrapper in Rust/WASM here: https://github.com/dakom/awsm-web

The idea is that it does more cacheing of things like uniform locations and such so you do very fast in-memory lookups in WASM without hitting the JS Api as much.

In the future this will be obsolete since WebGPU has a more optimal API to begin with, and Rust/WASM won't need to go through the JS layer due to "interface types"