深入分析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，所以我不清楚這是否可行。但這確實很有意義不是么?

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈