最近百度开源了他们的"js框架"Tangram , 之前听说这件事时,还是很期待的, 但是当真正看到Tangram时 还是有些失望.
打算在这里简单谈一谈我对它一些看法.
这里所说的"看法"几乎没有技术相关的东西,详细的技术分析 稍后再写, 毕竟还没有把代码通读一遍,不好妄下结论.
首先声明一点, 虽然百度公司的名声似乎不好, 但是百度的技术人员是值得敬佩的,他们几乎个顶个的都是牛人.
这个绝对不是拍马屁(没必要拍), 我参加过很多技术交流会,每次凡是由百度技术人员进行的演讲,都会让我赞叹不已.
而百度在技术社区积极分享的一些技术资料也很有含金量.
下面进入正题吧, 说一说Tangram.
=====================
原来是个"库"
这个绝对是我个人的问题.
我一直期待着一个'开源的js框架",可是 最后拿到手里的却根本不是一个框架. 基本上只是"把一个一个(或者说一组一组)的功能函数,累积到一起, 最后产生的一个工具包".
到底是框架 还是 工具包 其实无所谓, 各有各的长处, 并不是说工具包就不如框架.
不过还是有点小小的失望.
=====================
让人不爽的"baidu."前缀.
这点也是网上反感最大的. 也许名字本来是无关紧要的东西. 但是事实并非如此.
@lifesing 在< 关于jQuery和YUI, 还有KISSY>这篇文章中 ,
有对"软件名称"的一点点讨论.其中部分观点还是很有价值的,节选如下:
"
YUI 的开发团队，太强烈的 YAHOO 色彩，真有可能是成也萧何，败也萧何。
如果真的哪一天 YAHOO 彻底没落，YUI 可能真的会很快成为历史。
有公司在背后支持是没问题的，但不能太放到明面上说，更不能产生强依赖。
比如提起 jQuery，我们并不会立刻想到 Mozilla. Mozilla 只是默默的支持者。
Prototype 和 MooTools 等也是，我们不 google 一下，甚至不知道 Prototype 和 MooTools 背后的公司是哪些。
YUI 的 Y, 使得 YUI 很难彻底开放开源。
"
这个问题百度Tangram自己也已经意识到了, 承诺未来会改变, 期待.
=====================
代码组织 & 需求
因为要满足"函数级别的按需构建", 所以tangram选择了一种通常很少见的代码组织方式:
每一个公共函数 一个单独的文件.
同时 在定义每一个函数的时候 都使用 全名(含有百度前缀和模块名称等),例如:
下面6个函数, 分别放在
tangram\baidu\dom目录下的 6个js文件中.
// getPosition.js
baidu.dom.getPosition = function(){}
// getPosition.js
baidu.dom.setPosition = function(){}
// getPosition.js
baidu.dom.getStyle = function(){}
// getPosition.js
baidu.dom.setStyle = function(){}
// getPosition.js
baidu.dom.removeStyle = function(){}
// getPosition.js
baidu.dom.removeClass = function(){}
如果我们某个页面只需要其中的前4个, 那么选中后, tangram的构建工具 codesearch 会打包出一个文件,文件内容如下:
baidu.dom.getPosition = function(){}
baidu.dom.setPosition = function(){}
baidu.dom.getStyle = function(){}
baidu.dom.setStyle = function(){}
这个地方, codesearch的设计者明显是偷懒了, 以他们的技术实力, 构建出下面这种 更精简的代码 是完全没有问题:
baidu.extend( baidu.dom , {
getPosition : function(){},
setPosition : function(){},
getStyle : function(){},
setStyle : function(){}
})
如果不喜欢上面这种方式 构建成这种也完全没有问题:
(function(){
var M=baidu.dom;
M.getPosition = function(){}
M.setPosition = function(){}
M.getStyle = function(){}
M.setStyle = function(){}
})()
反过来看, 如果源码存放时, 就是按模块一体存放的,如下 放在 baidu/dom.js里
extend( baidu.dom , {
getPosition : function(){},
setPosition : function(){},
getStyle : function(){},
setStyle : function(){},
removeStyle : function(){},
removeClass : function(){}
})
那么根据需求 构建出
extend( baidu.dom , {
getPosition : function(){},
setPosition : function(){},
getStyle : function(){},
setStyle : function(){}
})
也不是难事.
反正我觉得可以优化的地方很多, 而且使用到的函数越多优势越明显.
而目前百度的 codesearch 工具在构建文件时, 很可能是做完依赖的判断后, 只是简单的读取文件 拼接文件, 而没有做进一步的优化.
所以 我不得不认为"codesearch工具的设计和开发人员偷懒了".
"函数级别的按需构建" 的一个目的是为了让引入的js代码尽可能的小, 但是Tangram现在的做法并没有做到最好.反而在很多地方让代码变得冗长了.
即使上面的做法都不可取, 那么"每一个公共函数 一个单独的文件,函数用全名称定义" 也绝对不是解决"函数级别的按需构建"的最好方案, 更不是唯一方案.
关于代码构建和组织, 我稍后会写一篇我的观点和看法.
我一直很推崇 对IDE友好的 js代码组织方式. 所谓对IDE友好, 就是可以让那些比较流行的IDE可以清楚的显示出 js代码的 outline 以及进行 方法的跳转 查找等. 把函数一个个的拆开存放, 我觉得不是一个好办法.
========================
codesearch 也应该提供下载, 让用户可以在本地构建Tangram
这个没什么好说的, 我觉得这个需求一点也不过分.
========================
开源的目的和意义
看到 Tangram的成员在博客上说 :
"tangram首先还是针对百度产品线的，主要用户也是百度产品线，不是说开源了希望有多少人用这个库，开源更多的是种开放和互相学习的姿态。
"
如果开源的目的不是为了"让更多的人使用这个产品, 让更多的人对产品提出有益的建议, 给更多的用户带去价值, 从用户那里获得不断进步的动力和成就感",
而仅仅是为了"表达百度的一个开放和互相学习的姿态",
那么这种开源是不是可以理解为"面子工程"或"市场行为"?
而对于Tangram的人员来说, 是不是可以理解为只是一个"政绩工程", 只是你们年底KPI考核时的一个正值?
难道开源的意义就是"摆一个姿态给大家看"?
开源者 除了要有一个开放的心态, 也要有梦想有野心, 不管是否有人相信,不管是否能够实现, 至少喊出来, 感动一下自己 也是好的啊.
所以, 我觉得不管 百度 官方是怎么指定的目标, Tangram团队还是应该给自己提供一个更高的目标和要求.
======================
先说这些吧, 具体的技术细节的讨论下次再说.