jQuery 在 2.0 以后的版本也去除了對低版本 IE 的支持

jQuery 的選擇器可以用 document.querySelector() 代替，其他也有可替代的方案。

至于輪播圖、選項卡，用 react 或者 vue 可以很方便的和其他項目結(jié)合，還是比 jQuery 可維護性強一點的。

我覺得在需要大量處理瀏覽器兼容問題的時代，jQuery 是非常方便的，但是現(xiàn)在 jQuery 有點高不成低不就的意思。

倒不是說 jQuery low，說這種話沒意思。只是個人覺得沒什么用 jQuery 的必要。

當然，具體問題具體分析，如果公司項目確定了用 jQuery ，也還是可以的。

jQuery并不“l(fā)ow”，隨著互聯(lián)網(wǎng)時代不斷的發(fā)展，網(wǎng)站的邏輯越來越復雜，jQuery已經(jīng)很難滿足復雜的web開發(fā)，而且很難維護，所以Vue等框架應時代而生，解決jQuery很難解決的問題，考慮了以前開發(fā)的問題現(xiàn)在出現(xiàn)的問題，將來可能出現(xiàn)的問題。

jquery是庫，其他兩個是框架，庫和框架是不一樣的,我覺得放在一起比沒什么意義。我只是一個前端渣。

不同的應用場景 選用不同的庫

不知道樓主從哪看到的說 jQuery 很 Low , 我不敢評價三個哪個好哪個不好 哪個 low ,因為我沒寫框架和庫, 但是jquery 就是跨了一個時代 方便了前端 . 還有 jquery 直接操作 dom , 其他兩個框架虛擬 dom, 是因為簡單情況下我們直接操作 dom 更方便, 但是虛擬 dom 可以讓 web 應用更復雜. jquery 是可以做大型應用 (原生 js 一樣可以), 但是這復雜了工作, 我們工作是為了簡單, 所以哪個適合自己, 哪個簡單用哪個, 殺雞用牛刀也是一個道理, 可以用 但是累.

任何一個大佬都不敢說 jQuery 是 "low" , 最多只是 "過時",

過時是真的過時, jquery 是 web 2.0 時代的王者,

拋開兼容性問題(反正遠古瀏覽器早晚會被淘汰的),你說的 輪播圖、選項卡 用 ES6 可以寫出很精致的代碼, 用class 可以很好地將這些玩意封裝成可復用組件,使用 jquery 只會拖性能的后腿,

目前,大型項目我選擇 webpack + react , 小頁面(特別是移動端)我選擇原生, 只有修改老項目的時候,我才會用到 jquery

先祝大家新年快樂，感謝參加討論的朋友，為了讓哪些噴子住嘴，我還是自己總結(jié)下吧。網(wǎng)頁特效含小規(guī)模DOM操作場景下，還是jQuery或原生語法更合適些，特別是現(xiàn)在的3.x系列體積很小了，實在不行的話Zepto也可以。

而大量DOM操作用JS做視圖控制的場景下，React和Vue具有一定優(yōu)勢（新的技術、設計模式），這使得性能和開發(fā)效率得到一定提升。最主要是這個時代的組件化開發(fā)模式，使得團隊協(xié)作（項目維護）變得更容易，React和Vue這類庫提供了組件化更優(yōu)實現(xiàn)。

與君共勉

其實部分原因是取悅開發(fā)者，便于項目維護。

回答這個問題需要從React的起源開始：

React 起源于 Facebook 的內(nèi)部項目，因為該公司對市場上所有 JavaScript MVC 框架，都不滿意，就決定自己寫一套，用來架設Instagram 的網(wǎng)站。做出來以后，發(fā)現(xiàn)這套東西很好用，就在2013年5月開源了。

那么這個問題實際上是：

我們?yōu)槭裁匆肕VC軟件設計模式？

MVC模式的優(yōu)點：

耦合性低

視圖層和業(yè)務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業(yè)務流程或者業(yè)務規(guī)則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數(shù)據(jù)層和業(yè)務規(guī)則。
模型是自包含的，并且與控制器和視圖相分離，所以很容易改變應用程序的數(shù)據(jù)層和業(yè)務規(guī)則。如果把數(shù)據(jù)庫從MySQL移植到Oracle，或者改變基于RDBMS數(shù)據(jù)源到LDAP，只需改變模型即可。一旦正確的實現(xiàn)了模型，不管數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務器，視圖將會正確的顯示它們。由于運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據(jù)這種設計思想能構(gòu)造良好的松耦合的構(gòu)件。

重用性高

隨著技術的不斷進步，需要用越來越多的方式來訪問應用程序。MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因為多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產(chǎn)品，雖然訂購的方式不一樣，但處理訂購產(chǎn)品的方式是一樣的。由于模型返回的數(shù)據(jù)沒有進行格式化，所以同樣的構(gòu)件能被不同的界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現(xiàn)方式，而控制層和模型層無需做任何改變。由于已經(jīng)將數(shù)據(jù)和業(yè)務規(guī)則從表示層分開，所以可以最大化的重用代碼了。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會話的購物車和電子商務過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應用程序所重用。

生命周期成本低
MVC使開發(fā)和維護用戶接口的技術含量降低。

部署快
使用MVC模式使開發(fā)時間得到相當大的縮減，它使業(yè)務程序員集中精力于業(yè)務邏輯，界面程序員集中精力于表現(xiàn)形式上。

可維護性高
分離視圖層和業(yè)務邏輯層也使得WEB應用更易于維護和修改。

有利軟件工程化管理
由于不同的層各司其職，每一層不同的應用具有某些相同的特征，有利于通過工程化、工具化管理程序代碼?？刂破饕蔡峁┝艘粋€好處，就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進行處理，然后選擇視圖將處理結(jié)果顯示給用戶。

MVC模式的缺點：

沒有明確的定義
完全理解MVC并不是很容易。使用MVC需要精心的計劃，由于它的內(nèi)部原理比較復雜，所以需要花費一些時間去思考。同時由于模型和視圖要嚴格的分離，這樣也給調(diào)試應用程序帶來了一定的困難。每個構(gòu)件在使用之前都需要經(jīng)過徹底的測試。

不適合小型，中等規(guī)模的應用程序
花費大量時間將MVC應用到規(guī)模并不是很大的應用程序通常會得不償失。

增加系統(tǒng)結(jié)構(gòu)和實現(xiàn)的復雜性
對于簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結(jié)構(gòu)的復雜性，并可能產(chǎn)生過多的更新操作，降低運行效率。

視圖與控制器間的過于緊密的連接
視圖與控制器是相互分離，但卻是聯(lián)系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。

視圖對模型數(shù)據(jù)的低效率訪問
依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。

一般高級的界面工具或構(gòu)造器不支持模式
改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，會造成MVC使用的困難。

各大前端社區(qū)關于框架的熱門問題基本都是以上總結(jié)的低配或者魔改版

所以啊，還是要提高姿勢水平

來源百度百科：MVC框架

我不認為jq過時，使命不同，不存在誰替代誰。只不過vue等框架使用的場景范圍更廣一些。
比如做復雜的特效并且兼容低版本ie，應該jq更合適一點吧。做oa類的數(shù)據(jù)性的網(wǎng)站，顯然mvvm會好一點。