百度前端js代码库tangram昨天开源了，目前我在百度FE通用组， 也就是负责tangram开发和维护的组里实习，所以写写我个人的看法。
先不管这个代码库怎样，这是百度第一个在内部走流程正式开源的项目，挺有意义的，以后只要是跟tangram有擦边关系的东西都可以直接开源不通过层层审批，有了第一个开源接下来百度要开源什么东西也会容易一点。这个开源的推动挺不容易的，需要很多人很给力的推动才能成~
扯点别的，百度的技术氛围很好，内部前端的技术文章/调研文章相当多，为什么不扔一点到http://www.baiduux.com呢， 以内部文章数量一天一篇都不成问题，如果讲究高质量的话一星期一篇也没问题，这是毫不费劲的事，可以带来很好的口碑，但就是不这么做。之前我在腾讯广研也 有相同的疑问。开源和技术分享带来的好处以前说了，提升公司形象，吸引人才加盟，是成本很低的公关，对各方都有好处。想想腾讯的ISD和CDC博客赢得了 多少尊重。
扯回来，再介绍一下tangram，tangram中文意思是七巧板，这名字很形象，tangram本身粒度细分到函数级别，每一个函数对应一个文 件，所有代码都拆得很散，有支离破碎的感觉，有相应的后端工具处理这些函数的依赖关系，进行按需拼装，组合成自己需要的代码。可以在这里看到其中一个拼装 工具：http://tangram.baidu.com/tangram/codesearch.html
这个库的组织形式非常简单，没有YUI KISSY那样的沙盒/核心等东西，一个个方法都单纯地放在各自命名空间里。所以它不叫框架，叫库，提供各种方法，使用它们时不用像框架一样按照它们指定 的方式去写代码，其实就是一个工具箱，里面有各种工具可以单独挑出来带回家想怎么用就怎么用。
为什么会诞生这么一个库，因为百度内部产品线非常多，每个产品有各自的特征，每个产品的需求都不同，没法去要求每一个产品的前端都按照一个框架一个结构来开发，所以需要高度可拆装可定制的js库。
tangram追求高性能小体积，高性能除了ext大家都追求，例如baidu.dom.addClass里不会判断这个add的class名在节点上是否已经存在，即使存在也照样加上，因为这个判断会消耗一个正则的性能，所以选择不加。
体积上会尽量避免写不是必要的代码，例如每个方法里都不会有参数类型判断。每个方法尽量减少对其他方法的依赖。事实上这点在UI上还做得不好，现在 如果单独拿其中一个UI出来用，把它依赖的方法都取出来体积还是挺大的，特别是那个UI有动画的情况下。事实上我对代码的体积有点偏执，特别喜欢一个可用 的东西非常小，呵~
还有一点值得一提的是，tangram大部分代码都通过QA的专业测试和各产品线的使用，质量是很有保证的，我觉得QA的测试老高级了，全自动化， 看着他跑测试挺爽的，听这个高级QA讲一讲测试你会觉得测试是相当有趣的。unit test的代码也将会放在github上，上面说了，只要是跟tangram擦边的东西都会开源，只要公司乐意，大家对开源都很积极的。
tangram首先还是针对百度产品线的，主要用户也是百度产品线，不是说开源了希望有多少人用这个库，开源更多的是种开放和互相学习的姿态。事实 上我觉得如果是个人开发，没有非常特殊的要求，jQuery是唯一的最佳的选择，而团队开发，或有特殊要求才需要考虑用其他库/框架。
引用来自“whoisthat”的评论
如果你在写代码的时候，无论想干点什么，都要以“biadu.”开头的话，我很想知道你会有什么反应
======================================
/**
* 将字符串解析成json对象
* @name baidu.json.parse
* @function
* @grammar baidu.json.parse(data)
* @param {string} source 需要解析的字符串
* @remark
* 该方法的实现与ecma-262第五版中规定的JSON.parse不同，暂时只支持传入一个参数。后续会进行功能丰富。
* @meta standard
* @see baidu.json.stringify,baidu.json.decode
*
* @returns {JSON} 解析结果json对象
*/
baidu.json.parse = function (data) {
//2010/12/09：更新至不使用原生parse，不检测用户输入是否正确
return (new Function("return " + data))();
};
引用来自“whoisthat”的评论
如果你在写代码的时候，无论想干点什么，都要以“biadu.”开头的话，我很想知道你会有什么反应