之前有人不知道是自己想的还是从上家拷过来了一个框架，号称前后端做到了大统一。
具体是这样，在后端定义前端一个页面的所有基本元素和属性，在后端定义一个流程的所有前端页面跳转关系，在后端定义所有流程中的页面的属性。当然如果你要有自定义的控件，可以在后端定义一个自定义控件，给它一个id，然后前端根据id匹配。
这么一搞，所有东西都在后端规范好了，前端只是做map，或者就是调用一些common的东西，看上去貌似很简单。
但统一的背后，是丧失了灵活性。框架本身无法common的处理所有common的东西，不得不到处塞一些特殊处理，导致框架本身过于复杂，无法修改。然而特殊的需求越来越多，改动越来越难，bug也越来越多。
一个design出来以后，本来可以轻易的分给前后端两拨人做，现在两拨人没法独立的做了，必须要混在一起不停沟通一起搞才行，因为双方的协议从简单的api换成了一颗后端的config树，非常复杂。前端现在不懂后端没法干活，后端不懂点前端也没法干活。
这两拨人还分属两个不同的部门，跨部门沟通导致效率极低，代码的分解方式完美的违背了康威定律。
一旦某个东西要改，改前端后端报错，改后端前端报错，也不知道到底该先改哪个。
这个框架一开始做为提升前端perf的极其有效手段而被重磅提出，获得了CEO的点赞，并且已在某个大部门全面铺开，因为确实提升perf非常有效。还有个wiki专门写了为什么一定要用这个框架的9大原因。
这个框架相当于做了一大部分的数据预处理，用了它前端很多时候也不用再call api了，数据直接后端一一对应到前端的每一个控件，都给你做好了，统一一个api call回来，所以perf不能不快。
但其实，提升perf有1000种方法，这个框架偏偏选择了最不应该走的路，首先api合并很多数据会有并发瓶颈，其次还是前端丧失了灵活性。
损失什么都不能损失了灵活性，这是现代开发的一大要求，因为变化总比计划快。
为什么这样明显的anti pattern框架能得到流行呢，因为它除了perf快，还有一个卖点是大统一。
人类的潜意识里总是梦想着大统一，物理学宏观微观的统一，国家的统一，代码的统一，所谓“同样的代码不应当出现在两个地方”。
但是，不妨问一下，为什么要统一。很多情况下，现实世界的事物无法统一，强行统一带来的就是可读性变差无法理解无法维护。
幸好我不是那个部门的，因为一些业务原因得以一窥他们这个框架的内涵，祝他们自求多福吧，以后避开坑组也是一个参考。