【转】JavaScript 函数库的未来

过去的几年里,函数库为JavaScript的突然风靡做出了巨大的贡献。JavaScript开发者因此而解决了难题,而且开发者在为感兴趣的问题开发解决方案的同时,又可以将这些应用到商业领域。

我一直在思考JavaScript函数库的未来是怎样的,其中我很希望引擎从API中分离出来。

选择器引擎(Selector Engine)的轻便性

函数库选择引擎的速度问题引来的争论实在不少,但前提是得看你怎么用它。所以我所谓的选择器引擎的轻便性指的是根据我的应用来自定义:可以根据从事的项目不断地更改选择器引擎。

例如:

  1. 构建一个完全的桌面web应用——我想使用尽可能全的选择器引擎;
  2. 为iPhone构建一个site版本——那我仅需要querySelectorAll因为它可以被支持;
  3. 构建一个移动设备可以连接的轻便版本,我会通过ID将JavaScript局限到目标元素以保持其紧凑性。

现在选择器引擎有越来越多的选择,尤其是当你知道如何自定义你的应用的时候。

我想看到的情况是:

  1. 我们是否能写出将新引擎导入库(如jQuery, Prototype, Mootools)的插件;
  2. 未来主流的函数库版本是否能支持可插型查询引擎(query engine)。

总之,开发者能够根据应用的具体需求而选择选择器引擎。

API的选择

一旦API与选择器引擎分离,函数库的选择就只是个人爱好的问题了。而且这种分离使得更多的公司能够创建基于现有引擎或APIs的个性函数库。例如,BBC创建Glow——他们自己的JavaScript函数库,是因为jQuery不支持Safari 1。

挑战

是否能有主流函数库的插件,能够让我们在函数库中接入新的选择器引擎?这是个挑战。我不是Prototype 和Mootools,所以我不清楚这是否可行。但这确实很有意义不是么?