Hi Matthias!
So if you look for the definition of a ECS, usually is (Wikipedia): “Every entity consists of one or more components which contains data or state. Therefore, the behavior of an entity can be changed at runtime by systems that add, remove or mutate components.”
Component will hold just data, and then you will have systems that will iterate queries of entities based on the components or values they have and will implement behaviour in there (logic). So there is a clear separation between data and behaviour, that’s why it’s also called a “data oriented” programming. So to your question difference between the ECS and ECSY framework ECSY, as Unity DOTS for example, both are ECS frameworks as they follow that paradigm.
A-Frame is more aligned with how Unity’s Monobehaviour works: Components have data (defined by its schema) but also logic (init, update, tick, remove, pause, play) and they could, and usually have internal state, like doing something like init() { this.whatever = new Vector3() } to hold a vector3 reference inside to help with calculations or so. So components themselves are not truly stateless and having logic break the rule of the ECS paradigm itself.
Then instead of having systems iterating over list of entities based on queries, you iterate over entities calling their components.tick() method, so you can still have system in A-Frame but they are not really mandatory, you could implement all your logic just on components.
And even so, your systems usually are tied to a specific components. For example if you define a Enemy component, you could have an Enemy system that will hold a reference to all the Enemy entities, but you can’t easily have a list of all the enemies that don’t have a target, or all the enemies that are dead, or so, are you are restricted to one component by default.
If you look at the graph, in both cases you compose the entities with a set of components but in A-Frame the logic is also hold in the components (you don’t really need systems) while in ECS you need systems to add logic and iterate over these entities and components, in the ECSY case by defining queries and calling execute() to loop through them.
So in my opinion defining A-Frame as an ECS is not exactly right, the same as you won’t call that for Unity’s MonoBehaviour (Which also have components and allow composition over inheritance), but more correct definition could be something like Component Based Architecture which doesn’t need to follow the ECS / data oriented paradigm.
