3mcd
commented
2 years ago 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.
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 :sweat_smile:. 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 :racing_car:. 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 :beers: