delete
我先占沙发，我有话要说
cocos creator本身就是一个大的 ecs 
还是有点区别
哈哈，手动点赞
ecs还是不错的
ECS的主要目的在于缓存友好，组件的存储设计是核心
官方首席点赞师
在逻辑层进行逻辑的分离也是不错的
你想说什么
这个可以回头我也用一下
个人觉得，cocos用ecs写游戏其实挺尴尬的。。小型游戏，没必要用这种模式的框架，不利于维护，让逻辑更复杂。
大游戏某些系统搞这个还是不错的，但是ui部分还是老老实实拼界面最好。
2赞
我觉得还是很容易维护的。ECS主要用来写核心的游戏逻辑（和ui不怎么相关的）。之前我遇到过几层继承的情况，看代码都要晕死。改成ECS后，逻辑扁平化看起来也轻松多了。
不利于别人维护。。。自己肯定可以。。但是逻辑一旦多起来之后，也不好维护。因为component是通用的。如果需求需要改某块component的某些功能，那就只能换新的component，或者把原来的component加一堆if else。这样维护越久，要么if else越多，要么component更多。或者2个一起多。
1赞
Component只有数据，功能逻辑在System里面。Component的数据尽量是内聚的，比如速度组件，只有方向和大小，尽量避免其他的属性数据。
在System里面处理逻辑一般是不需要判断Component，能进入System执行的Entity都是包含了满足条件的Component。
这个框架没考虑大型游戏，一般是中小型。中小型游戏前端也就2，3个人。遇到要改Component的情况，我觉得直接沟通好也没什么问题。
我的比这个库代码量更少，而且还是全面支持ts。可以考虑考虑
老实说，项目里如果看到人有动update，首先就过去喷他一脸。
2赞
很厉害
但是这种逐帧遍历的驱动方式，在对象多的时候效率会较差，需要设计各种dirtyFlag减少无效运算。
1赞
对象，普遍上几百个以内，上千以上很少见。
按百这个级别，完全可以忽略这个遍历消耗。