简单聊一聊百度的开源JS库:Tangram简单聊一聊百度的开源JS库:Tangram最近百度开源了他们的js框架Tangram
简单聊一聊百度的开源JS库:Tangram
简单聊一聊百度的开源JS库:Tangram
最近百度开源了他们的"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文件中.
即使上面的做法都不可取, 那么"每一个公共函数 一个单独的文件,函数用全名称定义" 也绝对不是解决"函数级别的按需构建"的最好方案, 更不是唯一方案.
关于代码构建和组织, 我稍后会写一篇我的观点和看法.
我一直很推崇 对IDE友好的 js代码组织方式. 所谓对IDE友好, 就是可以让那些比较流行的IDE可以清楚的显示出 js代码的 outline 以及进行 方法的跳转 查找等. 把函数一个个的拆开存放, 我觉得不是一个好办法.
========================
codesearch 也应该提供下载, 让用户可以在本地构建Tangram
这个没什么好说的, 我觉得这个需求一点也不过分.
========================
开源的目的和意义
看到 Tangram的成员在博客上说 :
"tangram首先还是针对百度产品线的，主要用户也是百度产品线，不是说开源了希望有多少人用这个库，开源更多的是种开放和互相学习的姿态。
"
如果开源的目的不是为了"让更多的人使用这个产品, 让更多的人对产品提出有益的建议, 给更多的用户带去价值, 从用户那里获得不断进步的动力和成就感",
而仅仅是为了"表达百度的一个开放和互相学习的姿态",
那么这种开源是不是可以理解为"面子工程"或"市场行为"?
而对于Tangram的人员来说, 是不是可以理解为只是一个"政绩工程", 只是你们年底KPI考核时的一个正值?
难道开源的意义就是"摆一个姿态给大家看"?
开源者 除了要有一个开放的心态, 也要有梦想有野心, 不管是否有人相信,不管是否能够实现, 至少喊出来, 感动一下自己 也是好的啊.
所以, 我觉得不管 百度 官方是怎么指定的目标, Tangram团队还是应该给自己提供一个更高的目标和要求.
======================
先说这些吧, 具体的技术细节的讨论下次再说.
还是那句话, 代码build工具的开发人员, 不要给自己的懒惰和不担当找任何借口.
2.在不需要baidu.extend的代码里这样做还要另外引入这个extend方法，浪费
extend函数能有多大的成本啊.如果觉得成本大,写成
fins.test = {
...
}
好了.
3.lifesinger说了，体积反而变大了
这个不是一定的.
而且"代码总大小 代码中重复字符数,gzip压缩后大小"三者之间的关系是非线性的.
不能一概而论.
=================================
单独的比较两者优缺点没什么意义 , 因为各有优缺点, 而且对于不同的人 优缺点也有所不同.
百度有强大的测试 QA做保障,还有很多牛人给你们开发辅助工具(如codesearch) 而且模块 框架的大的改动也不太容易发生, 所以很多问题 对于你们来说根本不是问题.
但是放到开源社区来看, 很多你们眼里不是问题的问题 都会成为问题.
方式A
fins.test.getPosition = function(){}
fins.test.setPosition = function(){}
fins.test.getStyle = function(){}
fins.test.setStyle = function(){}
很明显的违背了 DRY原则.
同时 方式A 在语义上面, 也弱化了模块的界限.
使得 fins.test.getPosition 本质上就是一个长名字.
和 fins_test_getPosition / fins$test$getPosition没什么区别.
让整个库显得杂乱无章.
而下面的代码
// fins.test 是一个模块
fins.test = {
// 这里是原生的基本内容...
}
// 扩展一个模块
extend(fins.test , {
// 这里是扩展的内容
}
显然语义性更强.
当然 你说的那些方式B的缺点我也承认.但是如果方式A 真的如你所说的有很多优点, 而方式B缺点明显. 为什么大多数开源js框架都会选择类似方式B的做法呢?
开源就不能总是按照作者自己的主观看法,多听听大家的声音, 多看看大多数人怎么做的.
并不是所有的"特立独行"都好过"随波逐流"的.
你们内部是不是都认为 一个函数 一个文件的组织方法很好?
应该是在build的时候让用户自定义选择输出风格，
并注明风格A经gzip后更小，风格B在不gzip的时候较小
