I :heart: this effort

[NateTheGreatt]

Hey @3mcd!

First off, I recently read this blog post and super appreciate the shoutout and that you are also trying to bridge the synchronization gap between SoA and objects. I don't feel so lonely now 😅. Also, great job implementing archetypes! I still haven't had time to implement those.

Second, I was hoping that you would be willing to weigh in on an alternative way forward for the synchronization of data between SoA and objects that I drafted a short proposal for. As always, my focus is performance 🏎️. I believe this method of synchronization can bring the most performance benefits and provides an extreme level of interoperable flexibility, but I am keen to get a wide variety of opinions on this. Let me know what you think!

Cheers 🍻

[3mcd]

Hey @NateTheGreatt,

Thank you so much for the note. So glad to see yourself and others (like @ooflorent) working through these problems. I think we'll have some consensus on the best ways to handle compatibility in JavaScript ECS libraries very soon.

I'll take a look at your proposal for bitECS as soon as I get a chance. It looks promising, although I'm curious about interop with libraries that already use getters/setters, use frozen/sealed objects, etc. It would appear there's no way around those constraints with the proposed in-place override strategy. I'd also be interested to see how much overhead the accessors add in the context of the library. For example, are you adding significant overhead by replacing a basic object property with an accessor if three uses x/y/z heavily for internal computations as I'm sure it does.

I'll be sure to leave a much more thoughtful response in your discussion as soon as my time permits. Thanks again for reaching out.