2010年12月24日星期五

Tangram 前端库通过 Github 开源了

Tangram 是百度内部一直在开发和使用的前端库之一,功能与 jQuery 、 Prototype 等库类似,主要功能是简化 DOM 操作,并且扩展 JavaScript 语言。这部分功能准确来说属于 Tangram Core ,另外一个叫做 Tangram Component 的库提供一些类似 YUI 、 Sencha 这个级别的组件。

之前 Tangram 说要开源很久了,一直卡在流程上,并且也有人觉得必须把库做得足够好了才好意思拿出来开源。我个人的看法是,跟 John Resig 的一样,前端库应该从第一天开始就开源,因为就算你不开源别人也一样能看到,所以还不如开放出来接受别人的贡献。如果你写得不好,就算你不开源,别人要看也还是能看得到的,所以还是直接把代码晒出来好了,看得不顺眼的可以直接说,实在看不下去了可以动手改,改完了再把代码贡献回来。

说完了我对开源的看法,接下来我们看看 Tangram 和 Git 分别有什么好,先从 Tangram 说起。

Tangram 能做什么

熟悉我的人都知道,我从来不讨论哪个工具更好的,我只讨论在特定的情况下哪个工具更适用。因此,我们来看一下什么情况下 Tangram 是适用的。

Tangram 的总体设计很大程度上是参考了 Mootools 的做法,就是将框架拆散到函数的级别,你可以引用单个函数,而不一定要加载整个库。这样做的好处是节省带宽流量,尤其适用于那些流量很大但 AJAX 功能不多的网站。百度的很多服务流量都不小,而且常用页面上需要的 AJAX 功能也不多,因此 Tangram 成为了一个很好的解决方案。

那么什么情况下 Tangram 不适用呢?如果你要写一个 AJAX Web App , Tangram 就没有什么特别的优势了,除非你尤其熟练使用 Tangram 。一个 AJAX Web App 本身就依赖于库中大量分散的功能,把一个库拆分到函数级别并没有什么意义。当然,在 AJAX Web App 中, Tangram 也没有什么明显的劣势,跟 jQuery 、 Prototype 都差不多,这时候就由团队成员对不同库的使用熟练程度来决定选用哪个库了。

现在 Tangram 的最大弱势在于,它缺乏一种机制让你对页面逻辑的描述变得流畅( fluent ),而这正是我们使用 DSL 时所追求的。过去我也说过 jQuery 是一种 DSL ,它允许你用一种很流畅的语言来描述页面的交互行为,这使得页面交互行为变得很容易管理──读懂别人写的 jQuery 页面并不难,在上面做调整也很简单。这是 Tangram 为了减少下载体积做作出的牺牲,不过我希望它将来可以通过编译工具等方法来弥补这个缺陷──例如说,我还是用某一种 DSL 来描述页面交互,然后这种 DSL 能够被编译为 Tangram 代码。

Git 有什么好

为什么选择开源到 Github ? Git 到底有什么好处?我觉得一个简单的例子就能很好地说明问题。

例如说,你想看看 Tangram 的源代码,那么你可以直接打开 Tangram Github 的首页,然后以只读的方式把代码都复制到本地。

git clone https://github.com/BaiduFE/Tangram-base.git

读着读着,你觉得 Tangram 写得也不是那么好,想改改看。于是你回到刚才那个页面上,点 Fork 按钮,然后就相当于把 BaiduFE 下面的 Tangram 项目整个复制到你个人帐号下了。你当然拥有你个人帐号下 Tangram 项目的完全读写权限啦,这时候你就可以把它复制到本地了。

git clone git@github.com:CatChen/Tangram-base.git

可以看到,这是我的帐号( CatChen )下的 Tangram ,不再是 BaiduFE 下面的。这时候你就可以随意改动啦,改动完提交就是了。

git commit -a -m 'Tangram improvement'

如果你习惯使用 SVN 或者 CVS ,那么你需要注意啦, Git 的提交都是本地的,不会提交到服务器上去。你 Github 帐号下的 Tangram 是一个仓库,你本地编辑的则是另外一个仓库。别忘记了,你刚刚是用克隆命令把 Github 上的仓库复制下来的。所以在提交后,你还必须用推送命令把本地仓库复制回 Github 去。

git push origin master

在这里, origin 是一个远程仓库的别名。因为你本地的仓库是从 Github 上克隆下来的,所以 Github 上的仓库叫做 origin 。默认情况下,仓库只有一个分支,叫做 master ,所以你要把本地仓库推送到这个分支上去。

这时候,你自己的 Tangram 是更新了。如果你希望 Tangram 的官方版本也接受这个更新的话,你可以点击页面上的 Pull Request 按钮,这时候 Tangram 的管理员就可以考虑从你这里把更新拉取到官方版本上去。

如果你在开发自己版本的 Tangram 时,看到别人的 Fork 有更新了,并且也想要那个更新,怎么办呢?你可以主动地从别人那里拉取,然后 Git 就会帮你完成合并。例如说,我发现 Leeight 那里在做的一个 Tangram 升级不错,尽管他还没完成这个升级,也没提交到官方版本中去,但我就可以先把这部分升级拉取到我本地的仓库中来。

git pull https://github.com/leeight/Tangram-base.git

这样子,我就能看到 Leeight 所做的升级,跟我正在做的改动是否能够良好地兼容了。或者,我可以先做一些依赖于他的升级的事情,等他把升级做完了并且被官方版本采纳了,我再向官方版本提出 Pull Request 。

可以看到, Git 对开源项目来说是非常友善的,尤其是跟 SVN 和 CVS 做对比的话。 SVN 和 CVS 尽管允许分支,但分支之后通常要到项目完成时才会进行合并,这时候主干已经发生了很多变更,合并起来就相当痛苦。 Git 允许你分支后随时从别人的分支拉取变更,同时你还可以在自己的仓库内做很多子分支,这就使得开源项目管理变得十分方便了。

小结

说了那么多道理,建议大家还是动手实验一下比较好。试用 Tangram 无需下载,直接创建一个页面然后引用我们放在 CDN 上的脚本即可,然后可以尝试按照入门指南做些简单的东西试试。

使用 Git 管理开源项目的话,推荐阅读 Git 开发管理之道 ,能够让你更好地了解 Git 项目一般是如何进行分支的,以及如何利用这些分支获得更好的灵活性。如果你想看完整的 Git 手册,可以看看 Pro Git 这本书,作者把这本书放到网上并且免费公开了。

最后插播一下小广告,我的 jsHelpers 库也跟随着 Tangram 开源了,大家可以来 Fork ,我很欢迎大家提交 Pull Request 。

没有评论:

发表评论