微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

深入分析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,所以我不清楚这是否可行。但这确实很有意义不是么?

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐