yui3在框架设计中的牺牲和让步(3)

5、颗粒化 or http请求数

这的确是一对矛盾，颗粒化带来了项目开发、管理、和代码重用的高效率，却又引入了更多的http请求数，好在yui提供了combo，可以将所有的http请求合并成一个。只需在YUI引入的时候配置下combo属性即可，高颗粒化的请求数瞬间降低一倍以上。在之前做雅虎关系的时候，在yui2和yui3pre并存的情况下，可以将请求降低到4个，yui2和3各一个种子，各自一个combo。当然这是在hack掉yui的loader的前提下。yui默认不会合并非yui文件（更多细节可以阅读基于yui的团队开发）。即使这样，我们仍然可以控制我们的http请求数，在不hack yui的情况下，可以解决部分性能问题。

6、懒惰加载 or 即时加载即时执行

上文提到，逻辑依赖沙箱，沙箱依赖的js文件则是延时加载的，这样就导致一个问题，当页面比较庞大的时候，会等待页面js加载完毕才会渲染动作，这样的用户体验不佳，而即时加载即使运行则可以渲染出模块后随即渲染动作，当网速一定的时候，两者看似是一对不可调和的矛盾，yui 动态加载的机制比较折中的处理了这个问题，A逻辑需要a.js，B逻辑需要b.js，A逻辑则只会在a.js加载完成后执行，而不管b.js是否加载完成，而当A需要a.js和b.js的时候，A则需要等待a.js和b.js都加载完成才会执行，B逻辑只需判断当前是否已经加载b.js，如果b.js已经在其他模块中引入进来，B则可以立即执行。但确定的是，所有的js的引入一定是在domReady后执行的，也就是说，不管怎样，动作的渲染一定是在页面html结构出来后才开始执行的，用户体验上还是会有损失。

7、面向接口的设计 or 面向dom的设计

我们知道jquery的插件习惯将所有的动作都加载到一个$(‘#id’)上，使用的时候只要执行类似$(‘#id’).init()即可。这看起来简洁明快，开发者的逻辑的思路也始终没有离开“节点”，很方便理解，而对yui3 的node扩展就不那么方便，从yui3的pre版到正式版，对node扩展的方法在不断的修改（更多细节看这里：扩展yui3 node的定时器），这也可以看出yui设计者在对node扩展性设计时的纠结和苦恼：要不要允许开发者去扩展node节点呢？大概是因为设计者们对prototype先天的弊端心有余悸。目前看来，设计者还没有完全走出纠结，尽管对node扩展相比yui3第一个预览版方便了很多，开发者仍然不能像写jquery插件那样优雅自如的对node进行扩展。相反，zakas却将更多的精力放在了widget接口的设计上，在这一点上，相比jquery，yui3则具有无可限量的优越性，因为在yui3中，组件不仅仅是组件，而是一个有血有肉的生命体，他可以出生，可以成长，可以被改造，可以死亡，组件在这些复杂的运行时环境中自我锤炼，因此，一个复杂页面在yui3的技术体系中，变成了一个由无数组件链接而成的生态系统，这种生物链所带来的设计创新和新视野是其他js框架无论如何也无法超越的。关于yui3的组件开发更多细节可以参照：基于yui3的组件开发1 和 克军在D2上的分享《从yui2到yui3看前端的演变》

8、苗条的身材 or 庞大的身躯

说到这里，大概会有很多人拍砖。其实jquery和yui同属两类不同的js框架，一个苗条纤细，一个身重如山，两者之间其实没有什么水深火热，只是使用范围不同罢了，类似jquery的轻框架的使用范围是博客级别的小网站，尤其适合单人开发，代码写一次不再修改，而且很适合初学者学习使用，给初学者带来自信。yui则使用与企业级的项目中的团队开发，项目维护周期远远超过开发周期，因此yui性能一定比不过jquery，jquery的续航能力也一定不如yui，没有最优秀，只有最适合。当然这自然也挡不住我个人对迷人的jquery的喜爱，只要我们能从各个js框架学到东西，能提高自己做前端架构的能力，就ok。

说了这么多，其实只有一个观点，人无完人，框架无完框架，缺憾之处必有权衡。以上YY，欢迎拍砖！