我都是一个js一把梭，啥逻辑都在这里，
你就是那个一个js文件里有1W行代码的人？
感觉得分情况,时间紧了得A,重项目得b,本身重项目就得定制很多东西
B为主，A为辅。除非做一次性产品，做长久，肯定以B为主，我自己的游戏，把sprite，node等等基础元素通通封装了一遍，直接使用引擎渲染模块，其他功能通通自己折腾，就算换个引擎只要支持js移植过去也是小几天的事情。并且cocos任意版本升级对我毫无影响。我只需要把sprite，node等和引擎相关部分重新改一下，就完事了。
当然做h5一次性小游戏，怎么快怎么来。能不用代码更好，比如直接用唤境引擎做跳一跳，估计几分钟就做好了。毛代码都不用写。
想不到大家讨论那么热烈，受教了受教了
我一般根据项目特点来决定。但我了解的，一般做过大项目的人会以B为主，A为辅
一般B为主都是考虑自己的架构思维不想与平台绑定，喜欢自己构建一套框架…终极想法是换个平台一样可以玩的飞起，虽然我个人不太同意这个说法，不过总得来说我认为爱好B方式的要更容易成为主程。
2赞
终于有人说这个问题了，不知道哪个好。我也接触过B，B的写法真的不习惯，不知道哪个更优
倾向b，a如果项目越堆越大那么后面接手的人可能会奔溃
2赞
刚从egret转过来的时候很喜欢A,做到现在明白了B才靠谱,只要是长期项目，不管时间允不允许,都要B，不纠结
+1
很多原生组件都需要二次封装扩展一些功能，比如红点等
领导懂技术就选B。不过大多数领导不懂技术，只会催，而且还会拿实习的张三比较，看人家进度多快，工资还低云云。
2赞
B+A…
看项目选择不同方案，倾向使用B，通用组件会用A
这不置顶三天嘛？
我倾向于使用C
2赞
没实际操作过，get不到点，这里的意思是会有另外一个工具来制作场景布局然后导出成配置文件？
我一般把a称为编辑器驱动，b称为代码驱动，这两个有一个很本质的区别是，谁来控制整个游戏的生命周期，a是完全相信游戏引擎可以很好的处理游戏的生命周期，而b是希望有更多的可控性，或者说希望通过自己的游戏业务框架去处理游戏内各种元素的生命周期。
对于这两个方案各有优缺点，个人会比较倾向代码驱动，编辑器驱动第一次开发效率很高，但是当你的ui很复杂，并且要频繁修改或者要换皮的时候，而且对于游戏来说，ui界面内容都很丰富，ui结构和层级大概率要调整，相当于你重新要挂节点做绑定，如果有个10几个要绑的，你自己写的可能还记得，但是别人做的让你换ui的时候就非常痛苦了，如果用代码驱动的方式，第一次花的时间会相对长一点，代码量多一点，但是后续的维护会比较轻松
然后还有当你组件节点很多，想要做优化的时候，编辑器驱动很大程度上依赖引擎本身的优化策略，很多情况下并不能很好的满足你的定制化策略，可控性比较差
如果是小型游戏，并且没有现成框架，用编辑器驱动可以快速出东西，但是如果是中大型游戏，建议还是用代码驱动的方式，把控制权掌握在自己手里比较好，先说这么多吧
6赞
应该是把节点的查找路径自动导出成变量，使用的时候是用变量查找，修改节点路径后重新导出就行了。和以前使用cocostudio制作的流程差不多。
作为一个从1.x版本一直过来的开发者，经历过N多编辑器崩溃、场景丢失之后。真的很害怕用A方案，B方案是最安全保险的方案。不过前面有人说框架用B，实际业务逻辑用A，这样也挺好。还是得按照实际需求来
真的这么多次嘛。运气也太差了啊