如何看待 jQuery?


1. 什麼叫「瘋狂使用」?鏈式調用你用不好就可以不用。除了動畫,jQuery有強制要求你鏈式調用嗎?就連ajax你也可以完全不去管deferred,就按照callback方式寫。

2. 「泛濫的插件擴展,質量良莠不齊」,這能怪jQuery?它提供了這個可擴展的方便,至於怎麼用,這就看使用者的自覺了。什麼都懶得寫,完全依賴插件,那還是不要追求那麼多效果。

3. 「更有甚者,盲目的使用jQuery,甚至誤以為jQuery是一門新興獨立的語言」,這真的不怪jQuery,它做得太成功,掩蓋了其他東西的光芒,只能怪使用者一葉障目不見泰山。事實上,當你的產品面向PC瀏覽器用戶時,jQuery能給你很大的幫助,但當你的腳步走得遠一點,遇到移動互聯網用戶,或者轉身去做Node.js時,就應該能知道jQuery不是一切。不過話說回來,jQuery好用,名氣大,這本身沒有什麼錯。

4. 「隨著瀏覽器日益標準化,新的DOM介面(諸如:querySelector、querySelectorAll等)已經可以漸漸取代jQuery的選擇器,強大的選擇器似乎正在漸漸的喪失光芒」,是的,如果你的產品所面向的用戶端是現代瀏覽器,那麼可以逐漸脫離jQuery。但我要提醒一句,jQuery不只是選擇器,起碼還包括樣式(各種CSS3私有前綴哦),ajax(原生xhr真不如promise化的ajax好用),動畫(這個可以用transition和animation代替,但動畫流程管理和css3私有前綴就呵呵呵呵了)。

總結:jQuery是在特定時空內,在特定環境下解決特定問題的一個類庫,不能解決一切問題。將心比心,你不能因為它做得好名氣大而怪他掩蓋js的光輝,不能因為插件水平不行而責怪它提供了易擴展的機制,也不該因為它有局限而責怪它沒有做得更好。用與不用,取決於你和你的項目,離開它你和你的用戶會不會過得更好,這是關鍵。


jquery的負面消息再多,你不還是要一樣去用?

你自己手寫個兼容ie6的selector試試?

你自己手寫個兼容ie6的domEvent試試?

你自己手寫個ajax方法試試?

你自己手寫個getStyle方法試試?

你自己手寫一個animate試試?

你自己手寫一個domready試試?

你要是都寫過,並用在了大規模項目中,你用什麼都隨便你了,你自然知道自己在幹什麼。

如果你沒寫過或者不會寫或者寫的沒jquery好,為了你自己,也為了別人,還是用吧。


AJAX 時代的先行者,新舊交界時期的引路人。

———————————————————————————————————————————

題主的一二三四五折射出的是 jQuery 大幅度簡化了 JavaScript 前端開發,提高了開發效率;其受歡迎就是這個原因。


正或反,其實真正取決於用它的人,JQuery本身沒有錯,關鍵在於使用者。


我曾近用js實現過css3的選擇器和動畫庫並且比jquery實現的更好。jquery,ext,dojo,mootools都用過一段時間。近年的出js框架就沒怎麼研究了。

我覺得眾多庫中,jquery是最好用的也是非常接近原生js的很薄的一層封裝。鏈式調用配合閉包和非同步回調,寫起代碼來給我一種流暢的感覺。鏈式調用能夠讓你模擬出英語文法的代碼句子,非常符合人的思維模式。另外jquery的跨瀏覽器兼容性也是框架的意義所在,減少重複繁雜的勞動。

不過,我覺得js本身的特性和原生的dom api是需要好好研究掌握的。在此基礎上,有興趣可以自己寫個框架,沒興趣的直接用jquery就是很好的選擇。

簡單一句話,jquery很不錯,要麼用要麼自己寫框架。原生js必須要掌握。


本身JQuery是基於JS編寫的一個框架。

其目的也是復用函數,簡化代碼。

我實習的時候,也是濫用JQuery。但並不是說初學者用不好。

網上各種插件確實是可以復用,但是一套系統用的功能是一樣,但是並不完全適用。

這時候,實習生只能看代碼,改。

沒有JS基礎怎麼改?當然是看W3C,夜復一夜年復一年,好了,終於弄清楚簡單的原理了。

這時候,實習生也該畢業了。這下就會分兩個選擇:換工作,留在原單位。

1、換工作:

我本身就屬於換工作的。

換工作前,我對JS基礎非常差,輪播我純JS手寫寫不出(現在也是)。用JQuery也是看網上才能寫。

所以去找工作的時候筆試各種不會有木有。面了幾次之後,不懂的回家查,因為是基礎,比如作用域什麼的。然後買了犀牛書看。我就覺得換工作,對於我的前端知識面又廣了很多。

目前找的前端工作,對Jquery也有另一方面的認識。還有現在寫代碼也考慮到了性能,可維護性等問題。

2、留在原單位的

這部分實習生我並不了解也不敢評論。

回到原題,JQuery對於新手來說上手非常快!開發成本與開發周期大大減少,這個是不可否認的事實。

對於取捨,我覺得還是看項目來定義。

其實代碼風格,每個人都不一樣的。

個人拙見,可以噴。


題主說的這些問題都有,但是很片面

1、鏈式語法問題,的確很頭疼,看下面代碼

$(".view div[style*="block"] .selected").click().click();

這是一個真實項目中存在的代碼,我估計大部分人在看別人代碼的時候遇到這一段都會在想WTF

它的確可以好好的工作,這麼寫也是為了解決一個問題,但實際上解決問題可以用更優雅的方法,這段代碼出自一個寫後台人之手,因為大部分使用jq的人其實並不擅長jq,加之語法上的不嚴謹,確實會出現第一條所說的問題。我覺得待日後湧現更多專業前端的時候這個情況能稍有改善

2、插件泛濫,插件的確越來越多,不過我並不覺得這是壞事,你看photoshop那個軟體,濾鏡筆刷一大堆,還不是過得好好的,你不用別人用,覺得插件不好可以自己寫

3、有的抄總比沒得抄好...你看網遊,對新手不友好的基本都死了

4、我見過這種人,「js已經淘汰啦,我擁抱jq啦」 ←真是好蠢...不過這不能怪jq,鍋還是扔給天朝教育吧(或者他自己)

5、 我用jq只有兩個理由,一個是選擇器一個是非同步,如果不符合這兩條我幾乎不用jq,取代jq選擇器?說這話的是誰,快來讓我研究一下腦結構

jquery本身"查即用"的方式非常適合dom操作,這也是為何jq使用鏈式語法,與其說取代jq還不如讓jq初學者多學學js,還有就是...

移動端總共沒幾個頁面用你妹的jquery啊(╯‵□′)╯︵┻━┻


在其它問題的評論下面我黒 jQuery 已經黒成習慣了。troublesome 的鏈式調用、混亂的函數參數、性能問題、糟糕的 naming、inconsistent 的 API……

這麼說吧,jQuery 就像是 PHP。隨手做一個「只要能用就行」或者「用一次就丟」的東西,或是在最短時間內做一個原型,最適合不過。要嚴肅地做大的東西,我看還是節制使用 jQuery 比較好。最多把 jQuery 當作一個封裝 DOM 操作與 XMLHttpRequest 的 utility library,而不是當作基石或者 framework。

/* 像知乎的代碼,就是把對 jQuery 的使用盡量局限到一個模塊下,不同模塊之間的調用時都不使用 jQuery 有關的類型和方法 */


當年 jQuery 剛出來的時候,圖標還是一坨屎(畫的不太好看的漢諾塔),我只是認真的看了幾行代碼,然後受益匪淺,後來再也不為各種問題發愁了,遇到的問題基本都能照著它的實現代碼找到答案。

本來以為被各種奇葩問題困擾得很鬧心的 js 瞬間變得既有趣又好用了。

我第一次給人演示 jQuery 代碼的時候,大家都認為這太神奇了。

記得好像jQuery剛出來不久,微軟的 ide 裡邊就直接接納了 jQuery。&<---這個道聽途說的


我用sublime text2看,有語法高亮哦親!


我的看法,由於個人知識面覆蓋有限,自身基礎不紮實,僅供參考:

jquery是常用的js工具方法的一堆封裝,他在一定程度上加快前端開發的速度,會縮短項目開發周期,會減少很多代碼。

為什麼他能夠像現在如此受歡迎,成為一種事實的標準,是因為他的封裝充分f考慮了開發者的習慣,在儘可能大的角度來方便開發者調用與二次開發,這是他的一個優點之一。具體體現在,類工廠鏈式方式的調用,比如:

$().show().animate(),比如set,get的統一參數處理。$().css("width") $().css({ width : 200 });

而且在早期版本兼容了低版本ie的很多bug,使開發的注意力真正的關注到邏輯與數據上來,而不是成天解決兼容問題。

其它優點不一一等等。

至於如何使用好jquery,jquery提供的方便快捷封裝在整個前端開發流程佔多大的比例?為什麼我們一定要建議先學js,在學習其它框架,這是我們要搞清楚的。

1. 其實如何使用好jquery,取決於原生js的基礎,什麼是原生js的基礎:

比如:js語句後面到底用不用加分號,不用加分號時在哪個地方有坑?

js裡邊單雙引號是否有區別,他的標識名命名規則是怎麼樣的,為什麼prototype與jquery都取$為他的工廠函數標誌?如果你將來寫一個,還有沒有其它符號可用?

js裡邊保留字,關鍵字,有哪些?each與普通的for循環有多大的區別,他的好處在哪裡,他的壞處在哪裡,我們什麼時候該用他,什麼時候不該用他,等等。

上面的這些知識,在任何一個jquery相關書籍裡邊提的不多,而這些恰恰是一個js初學者必須掌握的。

2. jquery在整個開發過程中充當了一個方便操作dom的工具方法集合,而前端開發除了操作常用的dom之外,還需要操作頁面的交互數據,模塊化開發,工程師發布等等。誇張點說:jquery只是前端開發中的一個部分,他沒有任何一處能力完全取代原生js。而且我們需要了解的還有很多,比如:angularjs, backbone, avlon等等,模塊化開發,比如seajs, requirejs,還有其它的打包工具:grunt,glup,fis等等的。而了解這些,需要的基礎是原生js的能力。

前面從個人的角度介紹了一下什麼是jquery,然後什麼是js,百度很多,不一一介紹。

3. 只有在學好原生js的基礎上,才能很多的學習jquery或其它框架。因為jquery與其它框架出現的初衷就是加快js開發,粗暴的理解,他對常用的js開發函數進行了封裝,所以js功底紮實,基本看api及說明就能很快的入手,這也是jquery及其它框架歡迎的根本。

然後個人建議:先學原生js,再學jquery,然後有空學習jquery源碼,才好更好的使用jquery。

其它的不多說了,有興趣加入高質量前端群:159758989 一塊探討JavaScript/jQuery/的魅力,前端的魅力,調試工具的給力等等。高質量,禁止閑聊,非喜勿進。


題中所說的好像都不是jQuery的錯,他沒有要求你把鏈式寫的瘋狂的不可維護,他沒有誘導你不去選擇良好的插件,也沒有提示你用複製粘貼網上垃圾代碼的方式完成編寫。這些壞習慣跟jQuery有什麼關係?踢不好球還怪風太大,射不進門還怪球門偏。


你用原生js寫十行,我用jq寫一行。我一般可以判定不會jQuery的應該不是一個合格的網頁編程人員。


Jquery 最遺憾的就是文件大了點。。。


樓門所說的,其實大多數前端開發人員都討論過。就我個人而言,jQuery還是要學的,為什麼這麼說,在公司做一些展示產品產頁,宣傳活動頁面,沒有什麼業務邏輯的存在,純屬炫耀蛋逼用的為何不採用jQuery呢?而你看大公司的核心業務,用jQuery的也不是很多吧。

合理的利用,感覺可以提高工作效率,再者說,jQuery的源碼還是有很多可學的地方,我感覺無論什麼框架或庫都有利有弊,合利採用及可。


那是用的人的水平問題


jquery是js的一個庫,你可以認為是對js的補充,提供了很多方便易用的方法,兼容性也好很多


這篇文章基本上回答了題主的問題

用jQuery的都是傻子? - 前端外刊評論 - 知乎專欄

正所謂「樹大了招風」,錯的不是jquery,當然也不是javascripte,畢竟人家只是個具有面向對象特性的函數式語言


JavaScript有許多嚴重先天缺陷,畢竟它爸爸把它造出來也沒花多久,這門語言好像是花了10天設計的?我覺得JavaScript必然會被替代

當然我說的替代不是瀏覽器這個沙箱里以後不再跑JavaScript,而是由其他語言來寫,然後再轉換為JavaScript——例如FunScript(用F#寫完轉換成JavaScript)、CoffeeScript等等。

JavaScript成為類似彙編語言一樣的東西,只有搞編譯(或者應該叫轉譯吧)器的人才去寫JavaScript,用JavaScript直接寫Web應用的人越來越少。

那麼jQuery就是這個演化過程中的必然,以後寫JavaScript的肯定越來越少,把jQuery視為這個過程中的一門新的語言我覺得也不是不可以。

至於你說的什麼大量的低質量插件擴展、大量的低質量程序員等等這是所有熱門語言或者框架的普遍現象程序員不按編程規範來寫並不是jQuery本身的黑點,個人還是看好jQuery的前景的。

所以現在一直在鼓吹原生JavaScript的,在我看來就像一直在鼓吹彙編萬能的人一樣。彙編性能在正確使用的情況下最強沒有之一是事實,但是並不是什麼都需要性能特別是性能需求不高的客戶端應用。所以業務使用中,如果沒有特別的性能需求,哪個開發起來快用哪個(反正是在客戶端跑嘛,伺服器端就不能這麼隨便)。


黑jq的人大多是由一些功底的jser,多半是看不慣一個新手瞬間就解決了自己無數次調試後得到的一個經驗,完成了自己引以為自豪的功能,假若把jq看成一個他自己寫的功能模塊,自然jq就變成了瑞士軍刀中的自宮刀,北大荒拖拉機中的戰鬥機,其實就是這麼回事。

個人建議js可以不學,jq一定要學,當然別給我說js不學怎麼用jq,難道你真的一點語言基礎都沒有嗎?我js不懂,php入手,一樣用的溜溜的。


不要互相噴了,很簡單,js要學,jquery也要學。


推薦閱讀:

為什麼現在很多富web應用只支持chrome即使最新版edge都不支持?
DOM與BOM分別是什麼,有何關聯?
為什麼 Chrome 不修這個 bug?
在 DOM 上存放數據是否是一個好的解決方案?
移動端滑動到底部載入更多,是如何做到的?

TAG:前端開發 | JavaScript | jQuery |