UI用MVC，战斗用ECS，做Avatar用ECS真的不要太方便了。
2赞
ECS并不牺牲可读性，在多人团队中也并不牺牲开发效率，在JS中真正用ECS的人在乎的也不是对性能有帮助，而是统一规范
对象放在arraybuffer 上 顺序遍历 处理 js能提高cpu缓存命中率吗？
不能
命中跟js无缘
ecs抛弃缓存命中
做的不过是从
unit -> all component loop
变成
a component loop
b component loop
好处在于，顺序是可以定义的，组件是解耦的，策划是不怕的，需求是随便乱加的，再也不怕后期被策划糟蹋完的unit lifecycle，新接手的人看不懂，自己也看不懂
这…在js上那ecs就是设计模式了。虽然没有缓存命中，硬要使用好处也不是没有，至少节省缓存带宽和垃圾回收。
就是面向数据编程，cpu可以友好，并且多线程执行只是附带的。
思考范式转变为我一个world，有几个system,system的执行顺序是什么，system需要query哪些component
world就是一个大功能整体，system是大功能里的单独流水线，component就是数据。
一旦这样解耦后，好处就是不怕任何新增需求了，完全可以自定义system插入到老的system里。
ui就不需要这种套路，因为ui太死板了，mvc，mve，mvvm够用。
你想的没问题。正常以对象单位为组件也可以套用这个逻辑，按照战斗流程通过事件拆分为流水线pipeline模式，每个pipeline处理单个或者组合的功能，逻辑更清晰明了。说ecs解耦是因为用单位对象方式没有实现为管道解耦的模式。
ecs原始的出现就是在静态语言编译器可以编译出大量稳定的simd指令和同类型数据统一读入极大提高缓存命中，极大性能提升。
大家可能经常认为有银弹能一劳永逸地解决棘手的问题，其实并没有，任何东西如果好处很大，那一定有很大的缺点在别的地方。
oop+pipeline
面向数据的oop
函数式的pipeline
事件驱动的状态机模式
或者说列式数据的ecs
这些本质上在上层实现是基本类似的东西。除非编译器能对逻辑代码进行特别指定的编译。 然而js或者说v8甚至是jit模式都不能稳定地大量编译为simd指令，所以作用不大。
另外，想补充一个。不是ecs解耦，是ecs的代码编写逻辑强制开发者不得不实现为类似pipeline的流程，是pipeline的流程在解耦。
十分认同，解藕的开发模式有多种，在没有自定内存布局， 高CPU缓存命中， 多线程并行处理chunk的ECS就是花拳绣腿。
这才是技术讨论的氛围嘛～～你这句话说的精辟，在JS中ECS对很多人对作用其实是基于开发行为的约束
1赞
确实是约束
也有其他好处的，比如新功能的扩展
当然也有坏处，调试会麻烦，代码理解也会跳来跳去
我好像在哪里看过，调试ecs，可以写专门的工具或者插件来处理，不然会比较麻烦
使用快照日志呗。ecs的快照可太方便了。一目了然。
看大佬论道受益匪浅