JavaScript函数库的未来

核心提示： 过去的几年间，函数库为javaScript的突然风靡做出了巨大的贡献，JavaScript函数库的未来，Javascript开发者因此而解决了难题，而且开发者在为感兴趣的问题开发解决方案的同时，能够让我们在函数库中接入新的选择器引擎？这是个挑战，我不是Prototype 和Mootools，又可以将这些应用到商业领

　  过去的几年间，函数库为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，所以我不清楚这是否可行。但这确实很有意义不是么？