bootstrap+jq+ES5 真的比react/vue/angular+ES6 low嗎?
bootstrap+jq+ES5 真的比react/vue/angular+ES6 幹活效率更低、bug更多、可維護性更差、更low嗎?
同意賀老的意見。low。
但是原因不一樣。而一個人的知見，是很難跳出他周圍的圈子和慣常環境的。你在日常工作中只操作 DOM，從天上掉下來的想法去了解數據流或者Observable ？遇到問題還是在 DOM 的圈子裡繞。
很簡單的道理。比如 React ，一開始就必須接受 view = f (state) 的思想。幾乎稍微深入的使用，就會開始思考數據的互傳，進而是單向數據流，最後深入到各種數據流方案的討論和選擇。rxjs ，Angular 等雖有不同，但都有共性: 你必須先接受它們的抽象思想，才能談得上使用。
一種老生常談的說法是，前端框架兩三年一換，倒不如以不變應萬變。我只能說，框架雖然換了，但它們的核心思想卻是一直有價值的。打個比方，明天出了個新的 XXX 框架，甚至不是在瀏覽器端進行開發，我用它開發一個複雜應用時遇到困難，我會想，不可變數據會不會可以簡化這個困難的複雜度，如果不行，Reactive Programming 的思路會不會有幫助。
守著 jQuery 的話，操作一輩子 DOM 么？哪天沒有 DOM 了呢？簡單的回答：是的。
我比較反感老是說什麼特定場景之類的屁話。
你要規定一個以純dom操作為直接目標而不給出真正需求也不允許程序員依據常理做任何高層抽象的所謂特定場景，然後說更適合用jQuery……
或者大家來比比寫hello world……
或者大家來比比寫H5遊戲之類明顯不在一個頻道上東西……
不知道是誰在耍流氓。
反正開發一般的網站，我這種寫了20年網頁的人，拿 bootstrap+jq+ES5 寫，跟一個有2年經驗掌握 react/vue/angular+ES6 的中級工程師比，我都不敢說我一定能比他效率更高、bug更少、可維護性更好。你們誰拍胸脯表示自己行的，可以過來跟我比一下使用 jQuery 和寫 ES5代碼 的水平先。
【更新】
有人問百姓網不是也用jQuery嘛！關於這個問題請看：如何看待百姓網的前端技術架構是jquery + jquery ui + webpack?
另外我稍微解釋一下「特定場景之類的屁話」。
其實我也會說「特定場景」或者「這要看情況」這種話。什麼時候說這個話呢？比如跟一個其實你不想跟他溝通的人。比如跟你一個你摸不清情況的人，怕對方是來坑你的，先來一句這種話，立於不敗之地，然後見機行事。
這類話呢，一貫正確，也就是信息量基本為0。
上面這種情形，對外談判，或者大公司里溝通（實際上是對內談判）很常見。談判的要義就是不要亂泄底牌，己方要避免信息量泄漏，先多多獲取對方的信息。
所以呢，真在特定場景，我也說「特定場景」的話。（好拗口）
（幸好我所在的公司里，無需面對這種情況。）
但是呢，我們是在知乎上，或者在其他純技術討論的領域，再說這種信息量為0的話，那就有失真誠啦。
當然有些答案確實寫了jQuery的適用場景什麼的，可能是真的受到了常見的這種說辭的影響。需要注意，有些人出來說這個那個適用啥的，不是聽他講適合就適合了，很多時候就是個託辭，背後的真正理由可能是「我們其實還沒有評估過新技術棧」、「團隊這點人只會老技術」、「老代碼一團糟，誰敢改」、「手裡事情做不過來了，誰管它」……
這些理由本身可能是正當的。
但是講那個話的人可能自覺不自覺也意識到其實是 low 的，為了顯得不 low 就告訴你們因為我們的場景特殊！（哈，XX特殊X情）
其實呢，我覺得比較好的辦法是，我也知道這塊咱們有點落後了（low 的「友善」說法），希望將來能改進，如果各位有興趣，正好加入我們，一起來改進啊！簡歷請投 百姓網官方招聘網站 ，嗯。
最近很多來我廠面試的同學都喜歡問一個問題：你們用什麼技術棧？
老實說這個問題真正很難一句話說清楚。
我往往是這麼回答的，從終端上看，我們涉及PC端、M端和APP端；從用戶上看，我們有C端、B端和自己。所以最終項目選擇哪個技術棧往往取決於這個兩個維度。
比如，我們的PC-C端項目，要考慮瀏覽器兼容性，SEO，防爬蟲等等多方面因素，所以技術棧可能jQuery就要比vue好一些，但是如果是M-C端項目，兼容性基本就可以忽略了，vue的優勢就大一點。
回到題主的問題，我認為技術棧沒有誰比誰更low，只有在特定場景下，誰比誰更合適。
我們選擇何種技術棧，往往要考慮兩個方面。
1.開發效率：比如我們要做一個活動宣傳頁，裡面所有內容都是靜態的，產品要求趕時間明天上線，那我們如果選擇vue來開發一堆一次性的組件，就顯得得不償失了，選擇html+css+jQuery應該就可以搞定。但如果我們的需求是開發一個可配置的運營平台，那vue的雙向數據綁定就派上了大用處，這時候jQuery就相形見絀了。
2.持續集成：項目上線並不是完事大吉了，後續我們還要面臨需求迭代、bug修復、合作甚至交接等其他問題。因此一個可持續集成的工程化項目架構就顯得尤為重要，項目架構和技術棧的選擇往往是密不可分的，但二者並不存在必然關係。比如在沒有ES6的年代，我們依然可以使用RequireJS或者seajs來達到js的模塊化，沒有webpack，我們還可以依靠Grunt或者gulp來構建我們的項目。
jQuery也好，vue也罷，這些框架只是時代的產物，在背後真正值得沉澱的東西是軟體工程的設計思想和不斷用技術推動生產力的可貴精神。
最後談一下ES6，ES6是JavaScript的新標準，也就是js的未來趨勢（其實已經來到了）。如果你依然使用js作為主要的開發語言，你就很有必要去學習並了解它，當然這個也和你用什麼技術棧無關。
內容由 58招聘FE 朱雀 提供
對 @陸離 的一句話很有感觸：
守著 jQuery 的話，操作一輩子 DOM 么？哪天沒有 DOM 了呢？
jQuery 程序員的眼裡只有 DOM，簡單粗暴，導致了前端很容易入門，但是稍微負責的邏輯就寫不出來了。
增加見過一個前端轉全棧的程序員，有一次問我：為什麼我在 nodejs 裡面獲取不到表單的值啊？
我過去看了一眼就懵了。他丫居然在 koa 框架裡面這麼寫：
var $ = require("jquery");
var username = $("#username");
這有什麼真的假的，你實際寫出來維護下不就知道了嗎……要讓代碼好維護，前端模板、自定義事件、可重用性這幾個點是逃不開的，那不如直接用考慮了這些問題的框架，尤其是你都不明白這個道理的情況下更是這樣了。用框架不一定讓你寫出好代碼，但它能讓你少寫一些代碼，所以在垃圾代碼率不變的情況下降低了寫出垃圾代碼的量。當然也不絕對，因為框架以前就是用jquery es5之類寫的，你水平夠自然也能寫出好代碼，但是……
ES6比ES5事少，很多技巧性的東西不用再去關注（比如閉包保護變數等），語言提供的表達能力也更強了，雖然有些設計看起來並不好看，但是整體來說進步還是可圈可點的。
React/Vue/Angular 有點削足適履，有人說好，當然有值得肯定的地方，但是你用起來未必爽，自己寫寫就知道了，多寫寫業務也知道我在說什麼。
jQuery更像拿磚砌牆，但是程序結構、模板、數據請求與dom更新、可重用性等等，這些東西繞不開的，你寫jQuery要做，寫React要做，無非是React等框架的設計隱含了這些東西或者其中的一部分。
你去找一找，jQuery也有mvc / mvvm的實踐。
誰low誰不low，我倒覺得沒有比較的意義，定位不同，價值也不同。
真要說一點的話，DOM消失我可能等不到了，jQuery某天開始停止更新與維護的可能性倒是更大。
是的
誠然，jQuery也可以寫的很模塊化，但是基於操作DOM的基本範式會給你一個很差的暗示，寫到最後，你的業務邏輯可能是基於 【click 鏈】的業務邏輯，程序的狀態不集中，亦不可追蹤，玄學debug，玄學過QA
之前有個簡單的登錄頁面，沒有用框架，用jQuery寫的，分享一些關鍵代碼
//工具函數
function bindHelper (root, els) {
const rootDom = $(root);
const ret = {};
Object.keys(els).forEach((q) =&> {
ret[q] = rootDom.find(els[q]);
});
return ret;
}
//初始化inline登錄表單
const headerLoginForm = {
loginCaptcha: false, //是否觸發了驗證碼邏輯
name: "headerLoginForm",
$el: bindHelper("#header-form", {
form: "form",
msg: ".alert-danger",
email: "input[type=email]",
password: "input[type=password]",
keepLogin: "input[type=checkbox]",
captcha: "input[name=captcha]",
captchaRow: ".captcha-row",
button: "button[type=submit]"
}),
init () {
const self = this;
self.$el.form.on("submit", function (e) {
e.preventDefault();
self.$el.msg.hide();
const payload = {
email: self.$el.email.val(),
password: self.$el.password.val(),
keepLogin: self.$el.keepLogin[0] self.$el.keepLogin[0].checked
};
$.ajax(); //具體實現略去
});
}
};
// 另一個彈出式的登錄表單
const popupLoginForm = {
loginCaptcha: false,
name: "popupLoginForm",
$el: bindHelper("#user-login-popup", {
form: "form",
msg: ".alert-danger",
email: "input[type=email]",
password: "input[type=password]",
keepLogin: "input[type=checkbox]",
captcha: "input[name=captcha]",
captchaRow: ".captcha-row",
button: "button[type=submit]"
}),
init () {
headerLoginForm.init.call(this); // 這個表單和上面的表單結構一致，直接復用邏輯
}
};
雖然沒有用到什麼高深的技巧，但是基本上實現了組件化和 DOM query 與業務邏輯的解耦，表單的某些狀態也是在組件內的變數中存放。後來這套代碼無痛地使用Vue重構了，非常自然。
然而這份代碼是我在使用了很久MVVM框架後回頭寫出的，我在大學時，也曾密集使用jQuery，也造了不少基於jQuery的輪子，但當我看到 AugularJS 初版（暴露年齡？） 時，我毫不猶豫地放棄了所有在jQuery上的積累。
依我所見，大多數使用jQuery的開發者是寫不出這個質量的代碼，但對於MVVM框架的使用者， 框架會強烈暗示你使用這種範式去開發。這就是框架的意義：有效提升開發體驗和代碼質量的下界
第一。Bootstrap不該出現在這裡。
第二。JQuery適合於前後端不分離的場景，只要你的網站還對SEO感興趣，不要做前後端分離，更不要用NodeJS或者是PHP中轉，這才是閑的蛋疼的做法。
第三。ES5會比ES6Low一點。
JQuery會比React，Vue和Angular Low很多。
簡單說，如果是可以用前後端分離的場景 ，你不用，你確實Low很多。
如果是在不能用前後端分離的場景你非要用，那樣不Low，但是最後會很SB。
low啊，你用vue不用vuex也low啊，連前端路由都沒有能行嗎？什麼，連服務端渲染也不做？知不知道這個能提高首屏多少的渲染速度？node層都不寫嗎，這叫什麼項目啊，還有這個webpack配置也太簡單了，那啥啥啥都不用，還讓我怎麼編碼？
這個問題，low爆了，明顯沒有經過大腦思考就來問問題
問問題前，先自己從個人經歷里分析一下，然後產生困惑後，不知道怎麼解答，才是一個問題出來的經過
找幾個代碼庫看看不就知道了。我用過的絕大部分jQuery插件，就算star上萬的都有很多bug。
當然可以強詞奪理說寫的好的jQuery代碼比其他框架好，這就跟有好的平台不用非得用php一樣。
這幾個新的庫設計上跟jQuery代表的不是一個時代，從代碼本身上就已經比jQuery不規則的設計好了。
如果你能寫很好的代碼，為什麼不想把自己的代碼建立在別人的好代碼基礎上呢。
快速開發展示的話，我覺得Vue跟jQuery一樣快，可維護性也很好。
不要技術站隊，之所以淘汰jquery完全是因為它缺點多
可以去看vue老版本，vue從設計之初就是搶佔jq市場的
同樣一個功能，比如讓一個元素隱藏or顯示
jq的做法就是寫一大長串選擇器，然後改css。而vue只需改個屬性，沒了。期間和什麼seo 和什麼前後端分離有一毛錢關係？
有人一提vue就說要寫組件，簡單頁面一個html對應一個js，js里一個vue對象，完全可以搞定所有功能。用jq就要寫一堆選擇器，講道理就不用寫選擇器這一條就足夠讓我扔掉jq了，好多抱著不放的我懷疑你可能有抖m傾向
而頁面需要複雜一點的功能時，直接抽象成組件。抽象層次越低越好，一個組件能搞定不抽兩個，不需要考慮擴展重用之類的，需求變化直接重寫。(要是大一點的項目，從立項開始，風格結構等就不會輕易變化，設計一套抽象層次更高的組件是合理的)
在軟體開發上ui描述可以說是純粹的體力活，過於複雜幾乎無法抽象，每個網頁的樣式風格，結構都不一樣。拖插件的問題在於你沒法自定義樣式。
你說要做個活動頁，那現在需要個彈出框或者懸浮氣泡，你準備去哪拖一個和你頁面風格一樣的插件出來？屠龍寶刀點擊就送，一點擊彈出個bootstrap的極簡風？？這時候你怎麼辦？改源碼還是重寫? 改源碼還不如自己重寫了，用jq寫...等你寫完我一個頁面都做好了，代碼少，可讀性還好。
這些還是小問題，等後期維護的時候，前面jquery寫那一坨麵條代碼越改BUG越多，最終重寫一坨更垃圾的。vue里完全不會有這問題，複雜一點的地方都抽象成組件了，組件之間沒依賴可以隨時替換
我解釋下組件是什麼，react官方的定義是"有限狀態機"，我補充一下應該是，「相同參數下返回相同ui結構對象的函數」 也就是說組件是天然解耦。你看兩個組件相互組合很容易，但你什麼時候見過jq插件套jq插件的？很難吧
vue2加入了模板編譯到render函數，徹底解決靈活性問題，這時候的vue才是react的競爭者
簡單頁面使用模板，複雜頁面模板+組件，網頁應用直接純組件，非常複雜的應用上jsx。官方自帶了vue-cli，輕鬆使用webpack. es6+等技術。可以說從簡單到複雜提供全套的解決方案
在我看來還抱著jquery不放的都像是現代化過程中死守傳統工藝的手藝人，早晚淘汰，隨著社區發展jq的使用場景會越來越少直到消失
但也不是說vue/react這類框架一點缺點沒有（ng2沒看就不說了）
組件化導致了單向數據流，導致了跨組件狀態傳遞困難（父子組件容易，兄弟組件困難），如果組件嵌套層次較深，就需要使用redux/vuex一類的狀態管理的工具，這又導致一個不算太複雜的網頁引入了一堆概念。對之前沒接觸過的人來說還是很有壓力的
另外也不是所有情況下都不需要操作dom，但這種場景很少，直接js改dom就行了
想到的就這些吧
不low，但是系統規模大的時候jQ和原生js更容易掉坑裡。
我現在用ng1.x比較多，項目裡面幾百個controller清清爽爽處理不同的界面交互各干各的，有需要通信的就用emit 和broadcast發個消息。幾乎無法想像用jQ來組織這幾千個ajax還有大批的界面渲染會是個什麼狀況。
所以我現在只在一頁js可以搞定所有前端事情的時候還繼續用jQ，否則一定會用ng。
===============
另：現在js是我的膠水語言，不涉及業務的東西幾乎都拿js寫（nodejs），很多類庫前後端通用，省心。
沒有low的技術框架，只有low的程序員。
好程序員能把jquery代碼寫的比react/angular/vue可讀性更好
low的程序員能把react/angular/vue代碼寫成uglify後的代碼真的low啊。然而這個世界上真的有很多low的東西啊。沒有人說low的就一定不能用或者不好用。但是low就是low啊。
Bootstrap,JQuery 輔助性的功能集合，react/vue/ng 不過是規範化的框架。這兩個是不同的東西。 這就好比你騎個自行車，或者開小車上班 和 做地鐵，火車上班 哪個都不low各有各的應用場景
脫離業務場景對比框架 就是耍流氓。
確實有許多非單頁、輕邏輯偏展示的業務場景JQ這種命令式的做法更合適。
三大框架確實帶來了前端更多的思考，使整個前端更加的工程化。框架也確實適合有更多數據 交互的SPA。
只會ES5、JQ。不願接受ES6和前端框架的想法最low你這樣比沒意思，沒場景，沒業務，沒項目時間。如果你這麼說，不用開發新框架了，都用原生 JS 屌炸天，為什麼還用 jQuery 呢？jQuery 出來的時候大家也說這不好那不好。如果真覺得不好我建議轉後端，你也會知道後端也一大丟輪子，然後還附帶不定時新語言福利。
bootstrap不應該在比較之內
本來以為技術上的鄙視應該是偏序結構的，現在看起來，是總的來說有偏序結構，局部有全連通有環子圖的這個一個，我也不知道名字叫什麼的東西（逃
推薦閱讀：
※為什麼一些公司招前端不想要培訓班出來的人？
※在學習前端時，你是怎樣消除你心浮氣躁，急於求成的心態的？
TAG:前端開發 | JavaScript | React | Vuejs |