| 導購 | 订阅 | 在线投稿
分享
 
 
 

JavaScript函數庫的未來

來源:互聯網  2008-11-06 07:16:16  評論

過去的幾年間,函數庫爲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,所以我不清楚這是否可行。但這確實很有意義不是麽?

過去的幾年間,函數庫爲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,所以我不清楚這是否可行。但這確實很有意義不是麽?
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有