爱用哪个用哪个，以前没有可视化编辑器不也是这么过来的么，，，，，
既然不想用编辑器，为何不用2dx呢，性能还更好
界面是界面，组件是组件，代码是代码，窗口是窗口，预制体是预制体。预制体这东西本来就有问题，很容易残留你以为你已经删除的数据，如果多人合作，预制体上又绑定了太多的东西，还混合修改，出现一次冲突没法解决，或者解决失误，简直。。。。。灾难级别。
写代码的人，你不能观看一次的速度，你也要看长久的速度，用A确实你单个界面的速度比B快，但是这辈子只写这一个窗口了吗？你第二个界面没可能复用吗？你第二个游戏没可能复用吗？换个 引擎就不考虑复用了吗？
当然这个也看项目的大小，对于很小的小游戏，看心情就好，大项目，自己掂量把
1赞
那是写的太差了吧
确实写的差，后面重构了
写了这么多年游戏，两个界面用同一逻辑的几乎不到 5%
有个问题，为啥非要争个高低，A和B各有优势，
那就把A和B的优点和缺点整合起来，做一个C:
A主要的缺点还是集中在阅读性，特别是繁杂的嵌套，看这种代码能让人自闭，那么就避免这么操作
B的缺点也很明显，不够直观，用代码绑定节点耗性能， 那就做一个通用的X组件，
讲一下这个X组件的作用：
1、X组件只有一个属性，nodelist， 专门放节点的，不定长
2、写个扩展，专门根据上面的nodelist数据导出一个B方法需要的数据类（不继承cc.Component）
3、X组件和数据类互相持有，数据类的生命周期追随X组件，也就是X组件onload的时候创建一个数据类实例
4、（最重要的）所有预制体，场景，都不允许挂载除了X组件外的自定义组件，也就是只能挂在X组件
5、数据类外放public，X组件不外放private，主要是避免出现外部修改组件内部节点的代码
还有说到复用，我觉得比较经常复用的，还是各种item，这类的逻辑复用还是有必要的
a方案 unity 和 cocos我太爱了
b方案 让我写laya和egret非常痛苦我再也不想回去了
我现在就在写所谓的ccc大项目已经上线日本一年了 mmrpg卡牌游戏 
2赞
确实，我也就是这么一说，表达一下而已
既然各有所爱，那么就融合吧，我自己写的一套模块架构可以 纯prefab + 脚本开发，也可以预制体挂脚本开发
个人认为用A方案加上合理的目录规划，统一规范的 prefab和node的命名方式，细化功能到独立到具体prefab 就不会出现重度项目难以维护的情况，主要看架构设计，既然用cocos编辑器来开发游戏，就要相信编辑器的能力，人家是专业的 没必要非得跟编辑器强行解耦，因为你处理的节点还是叫node,而非GameObject
换引擎这个因素加入到项目开发里我觉得完全是因为想得太多，2D游戏还有比creator做得好的吗？3D的话你换成Unity也跑不起来
对我来说B方案相比于A方案，就是绕着圈的使用creator提供给你的功能，不走直线，看起来貌似脚本和prefab解耦了，实际上你的脚本也许只认特定的prefab
总结来说：A方案看起来简单，代码写得少了，傻瓜似的拖拽，体现不出自己的能力，
B方案需要多写一些代码，看起来牛逼一些吧，应该是这样
5赞
直接使用active=true 看起来很low，体现不出框架的复杂度 
2赞
啥游戏啊 观摩观摩
哈哈、、 可能只有经历过的人才懂吧。
纠结AB最根本的原因主要就是 视图 和 业务 是否分离的问题，分离后需要自行管理模块，这就需要框架，不分离则一把梭
A，B 结合是正统！ 结合自己的实际来吧
パズルガ-ルズ 你去日本的googleplay搜一下或者日本区的AppStore搜
1赞
碧蓝+三消 
类似steam上那种三消么
哇，大家快出来看看奇观了，200层楼的帖子竟然都很和气地讨论技术，没有任何对喷和人身攻击，简直是社区奇观啊！
—本回复占据第200楼 —