vue,react之類的框架是不是弱化了對前端人員js水平的要求?

現在的vue,react之類框架是不是弱化了對前端人員js水平的要求?以前需要封裝一堆面向對象的組件,現在都是通過數據驅動視圖,前端最複雜的需要用到js的業務邏輯都讓state,props這些東西解決了,精通js還有什麼必要麼?反而是css和路由,組件等的規劃整理能力顯得更為重要。


是。要問是不是,那就是是。

絕大部分的網站、Web App 需求,可能只會用到 60% 的 js 知識。但總有那麼一些需求,不去觸及剩下的 40% js 知識,就不可能做到。React, Vue 帶來的是把這個 60%,40% 的比例變成了 20%,80%,初學者上手成本低到讓刀耕火種的時代過走過來的人髮指。

上個前端時代的先輩們書寫了足夠多的麵條代碼,他們把 90% 以上的 js 知識 cover 住了,胸中有數不完的 hack、trick,當看到 React, Vue, Ng 的時候,大腦是通透的,他們知道這些框架為什麼這樣實現,解決了什麼樣的痛點,組成框架的細節其實也是他們曾經嘗試解決問題時採用過的方案。

而當下的新兵蛋子是什麼狀態呢?自稱掌握了 React, Vue,可卻不知道怎麼引入 cdn、怎麼拆分 bundle.js、怎麼插入第三方的動態 scripts。他們要麼被某些範式侵到骨髓,要麼被語法糖甜到不能自理。

React 黨總要可悲地問為什麼要 bind this,Vue 黨則更可悲地從來不問為什麼不要 bind this;React 黨總要可悲地問為什麼不能用 splice, push, pop,Vue 黨則更可悲從來不問為什麼可以用 splice, push, pop;React 黨總要可悲的問為什麼 attach 到原生 DOM 上的事件可以傳入 statement 而 React 的 DOM 只能傳入 method,Vue 黨則更可悲從來不問為什麼 Vue 的 DOM 可以既傳入 statement 又可以傳入 method;React 黨總要可悲的問為什麼 Redux 要使用用 spread operation,Vue 黨則更可悲地從來不問 Vuex 怎麼可以直接 mutate store;React 黨把 React 的 Class 構造當成理所當然,Vue 黨卻不思考為什麼 Vue 不引入 Class 構造;React 黨被教條束縛到不知為何要用 prop& 同步數據,Vue 黨則被自由奔放到四處奔走呼喊恢復 prop.sync 或者以重造 event broadcast 與 event dispatch 為豐功;他們尚且知道要在 componentDidMount / mounted 初始化 jQuery(有些人則還要問怎麼在 React、Vue 里使用 jQuery),卻總是忘記要在 componentWillUnmount / beforeDestroy 做 gc 相關的工作,留下各種 timer、promise 在組件的生命周期後操作實例。很多本應掌握 Js 就自然通透的問題,被掛上 React 或者是 Vue 的標籤投放到了各個論壇、交流群以及知乎上。

其實這本身不是框架的問題,封裝、範式、數據流、語法糖本身就是框架的設計指標,設計地越抽象越值得其作者自豪,乃是現實使然。令人喟然的是新的開發時代阻隔了新人觸及底層的機會,不需要掌握多少複雜的東西又將將可用,經驗不如老人豐富,越發地容易暴露基礎不紮實的地方。尤其是好高騖遠,急於求成的人員又比較扎眼,既不沉下心來又沒機會探到舒適區外,進步的空間就隱沒了。畢竟編程無它,唯手熟爾。

題外話:不過現實看起來並不悲觀,由於教育水平提升、市場飽和、准入門檻提高、新人越來越聰明,新老人的差距其實很小,年輕且伴隨框架的演進的後發優勢,固然有空中樓閣的危險,但可以把更多的精力可以放到架構、組織、數據流的思考上,基礎薄弱的脫困的方法也不曾斷絕,如果轉變下曾經而夯實基礎的方法(死學苦幹),搭配幾本經典(這個隨便縐的,除了權威指南、YDKJS,JS 設計模式沒看過什麼正經的 js 書),把前人們留下的庫吃透(偏頗地提幾個 lodash, jquery, vue, vuex, react, redux, ramda, rx.js, koa, keystonejs, 學點 rails),就會很容易掙扎出技術的泥濘地了。再像學學 at 賀老,at 阮神 對 specifications 能查查就粘來 ,或者像 at 小右,at 司徒正美可以寫個 66 的框架, 新一代大牛們定然比老牛們不遑多讓。


感覺很多人沒理解問題的意思啊?

弱化了對前端人員js水平的要求

我的理解,這句不是說你用了還會導致水平下降,而是降低門檻的含義。從這個角度來說,有些框架是,有些不是。

所以我給joker的回答點了贊,雖然有些細節不一定是這樣,但結論我是認同的,那就是:

如果一個人js不好,還是有希望勉強用vue做出點東西的,但是用react很大概率寫不出來,所以react是強依賴於開發者的js水平的,所以vue對新手會比較友好一些。

但是,長期來講,不能滿足於勉強做得出東西,有很多基本功還是得慢慢補起來的,見過不少人連引用都不能很好掌握,這個還是要補一下的。

看一下必備需求:

vue需要你稍微理解getter和setter,然後就能湊合幹活了

ng1需要你深刻理解原型繼承,然後也能湊合幹活了

react需要你。。。寫不下,反正至少是中級jser

ng2的前置需求也不少


完全沒弱化。弱化的是拿 vue,react 之類作工具去實現業務的過程。相對於過去,分層更清晰更易於理解。

最近面試不少,其實對 API 熟悉的人都不多,更別說背後的實現原理。光是 react 生命周期夠理解理解的了。再說 vue,本身很簡單,上一些實時更新場景等,大多都講不出來。

再說原生 js 的能力,很簡單的工程場景,如果要做 redux middleware 呢。移動場景 react 太重太大吧,我們想實現一個輕量級的 react,問題是 react 什麼可以刪的,移動場景需要些什麼呢。好吧,都有輪子可以選擇,我們用輪子,有 bug 呢,功能不滿足呢。能討論問題不,能 pr 么。

當然,前端只是用用這些框架在做事么。最近面試面到一些同學在幹嘛,驗證碼碰撞(圖形圖像),工作流程圖(可視化),前端流程化 CLI(Node) 等等,都用 js 寫的,會寫么


如果一個框架的出現是為了提升這門語言的使用門坎和使用難度 那麼它根本沒有出現的必要


首先,框架和"面向對象"是不矛盾的,無論是父子組件關係,通用組件和特殊組件,mixin 代碼混入,都有很多地方可以體現出「面向對象」的思想。

之所以現在各個框架都在倡導數據驅動視圖,是因為這才更接近我們代碼的目的。為什麼我們之前要頻繁的用命令式去操縱 dom,因為沒有 原生的 object 沒法做自動的observe,臟數據監測當然可以,那總得前端工程規模夠大才有必要做這個事情,工程規模大了,代碼自然就需要個框架支持,或者說,在開發的過程中形成了框架,然後又被抽離了出來。

我們從歷史發展的角度看待這個問題,就不覺得奇怪了,題主之所以困惑,是因為你正好趕在了發展變革的這一時期,你可以想一下,在歷史上也許還有過這樣的聲音:

「你們這種語言都不支持手動回收內存,遲早要完。」

「H5播放器什麼鬼,比得上我大 Flash 一根腿毛么。」

「連給紙帶打孔都不會,算個屁的程序員啊。」

程序員要做的事情是解決問題,而因為工具的不足帶來的麻煩其實是一種阻力,當然你可以可以把這個當做技術壁壘,一定有很多人會宣稱原生 JS 是極重要的,你們用框架的不行,哪怕做項目比我快十倍,那你也是底層不穩,我這種從 IE6時代過來的前端才是有含金量的。

現在用易企秀之類的工具,隨便妥妥拽拽就可以做一個營銷頁面,但是定製的營銷活動依然報價很高。弱化了入門水平,不代表降低了技術含量。現在隨便一個人都可以在京東買一堆零件回來組裝台式機,但是真要自己修個硬碟,恐怕沒幾個人有這個能力。

最近遇到幾次關於滾動條的問題,最終解決的方法還是手動計算了 scrollTop 和 clientHeight 的關係,這是要靠你對原生的了解才搞的定。當然,如果不是遇到很特殊的情況,隨便網上搜個插件很快就搞好了,我也很傾向於先找個插件,實在不行在自己填一點原生代碼。

這就是一個行業成熟的標誌,隨著生產工具的升級,對工人的要求一定是下降的,從小手工業到量化生產的轉變是必然的事情,一些人從事量產工作,而這個行業也始終需要有人向前探索,開發更好用的工具以及解決特殊的困難。

題主可以努力做第二種人。


以前需要封裝一堆面向對象的組件,現在都是通過數據驅動視圖,前端最複雜的需要用到js的業務邏輯都讓state,props這些東西解決了,精通js還有什麼必要麼?

額,業務邏輯本身沒有被state,props這些東西解決,解決的只是從以前DOM操作的思想轉換為數據驅動視圖渲染的思想。另外,精通js也並不只是寫業務邏輯,你是想說用原生js寫業務邏輯算得上精通嗎?

我反而覺得這些框架的出現提高了不少人的工程思維,組件設計的原則,規範,顆粒度,通信等等,還有前面人所說的調試能力也提高了

在業務中你將這些框架棄而不用的話,理由是這些框架不能足以讓我精通js,這不合理,還是項目上線重要。


能提出這樣問題的還是年輕,或者業務太薄。

來做2b業務啊……

每天都會懷疑自己的。


react 不是, 但vue是。vue同時也弱化了對後端人員js水平的要求。

react 本質上就一個渲染層(view), 除此以外官方什麼都沒幹。路由功能、數據管理是第三方提供的。react 也不提供模版語法,條件渲染、列表渲染需要用 js 去處理,特別是遍歷對象會比遍曆數組複雜點,當然用 lodash 之類的庫可以很好處理。事件處理上,react 是接受方法本身,而不是模版語法里的那種字元串,因此會涉及到 this 的問題。這一系列的問題都依賴於開發者的 js 熟練度。更不用提 類、類的繼承、實例方法、實例變數這些面向對象的概念對寫慣JQ的開發者來說是非常陌生的。即使你是做後端,估計也會因為js面向對象的奇葩實現而吃虧。

但正因為 react 夠單純,什麼都是 js 。 也讓 react 很容易跟其他 js 庫結合。redux 、RXJS、typescript、mobx、Immutable.js,這些流行的 js 庫都和 react 有很高兼容性。可以說,react 和 nodejs 一樣,激起了程序員造輪子的熱情。 這也是為什麼 react 的周邊生態那麼繁榮。

而vue正相反,除了渲染以外的功能,作者也自己單獨寫了js庫去提供了。模版、組件化,都有一套自己獨有的語法。開發者只要(或者說只能)按照 vue 提供的方式去做就可以了,而不需要去深入了解 js ,或者特地去學 es6 ,或者去了解 js 的周邊庫。因為vue就像一個媽寶,它把能想像到的難點都給你擋住了。

vue 是為國內的js水平不高的前端或者後端程序員而生的,而 react 則是為了 javascript 程序員而生的。


我記得以前打wow的時候,最討厭的就是那種被帶刷上來的,掏個幾百塊就能搞一套T9什麼的新手彩筆

那時候就覺得啊,那幫帶刷的都是群消耗wow可玩性的蛀蟲並且時常苦口婆心地勸新手說好好體驗一下wow那些小任務的劇情,彷彿自己就是個偉大的佈道者。

而實際上,歷史的車輪滾滾前進,就連wow官方都推出了各種秒升滿級的增值服務。

後來想想,更多的還是覺得不甘心,自己按時刷本攢分讓裝備最後依舊混個一身破爛,無非只是因為那時候自己的時間不值錢,最後和朋友聊起wow來也只能以一個好像經驗很豐富的老玩家自居,一旦聊到那些個h本真是避之不及。

時代總歸是在進步的,我們不是機器人,能用mdn查到的東西沒必要背下來,知道怎麼用就夠了,我才懶得知道那麼多看似很牛逼實則無用的東西,抱著老想法的那群人終歸是要被歷史所淘汰,你讓我走路從寶山到閔行我也不樂意啊。

最近我帶著乾的小伙已經基本熟悉了vue的用法,讓他回去用他之前最擅長的jq結果他現在一臉懵逼,還時不時的會在繼續維護的之前的老業務里寫入一些vue的語法然後一臉不解地看著老代碼報的一堆bug,我覺得這事情本身就是一件好事,說明vue更順手條理更清晰對新手也更友好,我也沒必要和別人解釋什麼瀏覽器只能兼容到es3 什麼瀏覽器可以兼容es5 什麼瀏覽器需要另外hack,因為這些東西終將被歷史淘汰。

就因為用了vue,小夥子現在已經能夠自己照著我給梳理的業務邏輯自己搭項目自己debug

而我也有更多的時間去做些業務以外的事情,拓展更廣的知識體系,然後傳授給別人。然後大家都有提升。

以上


jQuery之類的庫是不是弱化了前端人員dom API、瀏覽器兼容的要求?


這問題思路清奇啊。

Rails是不是弱化了對Ruby水平的要求?

Django,Flask是不是弱化了對Python的要求?

這個思路完全可以延伸下去。

Java和OOP是不是弱化了對C的要求?

C是不是弱化了彙編的要求?

至於題目,我覺得正相反,框架提供了標準化,明顯前端人員要學的東西成倍增長,怎麼就弱化了對js水平的要求?一直不明白為什麼有人會覺得會React,vue完全不用會js就行一樣。。理解框架對js水平要求很高啊。


懶這個特性反倒促進了人類的發展

汽車是因為人類懶得走路

機器是因為人類懶得幹活

計算機是因為人類懶得計算(最先設計出來就是為了計算的)

汽車的出現走路的人少了,但是製造研發汽車人多了

機器讓做簡單重複勞動的人少了,但是讓工程師多了

計算機讓真正做計算的人少了,但是讓推理公式,設計程序的人多了

這事放前端領域同樣如此,框架幫我們做了很多簡單而重複的勞動,讓人們有更多經歷放在更高級的業務上,這並不一定讓前端變得簡單。因為需求提高了,前端真正變得更複雜


並不是,只是提高了在同樣智商體力水平下可以生產出產品的牛逼程度上限。


說實話這個問題的背景再提前都不足為過,就拿jq來說,大家都用jq的鏈式來寫代碼,原生js編程能力是不是就弱化了?編程能力是否就等於js的精通程度?當然不是,你願意花時間打基礎這當然是好的,但是你如果對抽象的框架運用自如,其實也沒有什麼問題,你寫JAVA/PHP/GO也不會從零開始,都是基於一套既有的框架或者模式。

唯一的問題可能是你需要自己編寫開源軟體的時候,需要對原生js有一定掌握。

當然,框架並不能解決所有問題,遇到一些很生僻的問題,還是要有一定原生js的理解能力才能解決(讀源碼),但是大部分情況,框架都會幫你考慮到,也會有解決的方案提供。

vue/react提出了一種不同於jq的抽象方式,並且被證明可行,其實本質上都是抽象,所以在這個問題上可以同等看待。

換句話說,正是因為這類抽象框架的出現,才使得我們的關注點開始偏向了架構,而不是來回糾纏於頻繁瑣碎的「小事」(各種dom操作以及數據變化之後的ui更新)上。如何組織SPA的路由,評估一個組件的價值,以及如何設計一個組件(入參、事件)等等。

想想現在關心的事情是不是比以前高大上了那麼一丟丟~

總之,站在巨人的肩膀上會讓你的視野更開闊,這無可厚非,因為很多時候我們都成不了巨人。


可拉幾把倒吧。

被弱化的那群人,幹啥都會被弱化。

遙想當年http://Asp.net火的時候,說你們這群人就會拉拉控制項,面試還被一個Java面試官鄙視了一番,

這就算了,jQuery火的時候,總有人一直叨叨個沒完說弱化了原生js使用,

煩不煩,

弱化了個毛線啊,vue react為前端帶來改變是巨大的,明明是提高了前端人員編碼水平。


什麼是「js水平」?如果定義「js水平」為這樣:

  1. 了解如何在JavaScript中實現各種面向對象的方式;
  2. 自己攢出一個JavaScript框架的能力;
  3. 在一堆紛亂的JavaScript框架代碼中理出頭緒的能力;
  4. 等等……

那麼React和Vue對這樣「js水平」的要求的確弱化了很多,因為就算不會上面這些技能,只要照著React和Vue的架子來寫,問題都不大。

但是,如果定義「js水平」為——使用JavaScript開發出厲害的應用程序的能力,那麼,有了React和Vue並不會對這樣「js水平」的要求降低多少,因為,React和Vue只是把重複了又重複的工作給抽象出來了,讓每個開發者不要再操心重複製造這些輪子,可以有更大的精力去解決每個應用特定的問題。

如果前端開發者是戰士,React和Vue就是他們的武器,而運用武器的技術,也就是JavaScript的技術,以前該有多好,現在還該有多好。

舉個可能不是很恰當的比方,前陣子去美國出差,周末到Gun Club去玩了把槍,有M4A1那種自動步槍,也有打小日本那種三八大蓋。有的朋友就喜歡三八大蓋,我試了一下,那種衝擊感,還有每放一槍都要拉一下槍栓那種操控感,可能就是招人喜歡的原因(沒錯,那種感覺就是自己用JavaScript寫框架的感覺:-);當然操作更簡單的是M4A1,用瞄準鏡對準靶子打就是了,還有激光瞄準儀,和三八大蓋相比簡直就是作弊。

可以這麼說,以前的框架就好比三八大蓋,React和Vue就好比M4A1自動步槍,一個可以讓你可以操縱每一顆子彈,發揮自己的微操水平,另一個則是把這些重複的事情都自動化,讓戰士可以去操心別的事情。

那麼,是用三八大蓋的作戰水平高?還是用M4A1的作戰水平高呢?

我想,肯定不能說當今美軍對士兵的要求比對二戰時八路對士兵的要求更低吧。


並不,如果不自己開發組件另當別論,要是自己需要開發些複雜的組件,對js的水平要求從來就沒降低過


所以angular已經不在討論範圍了么。

框架將開發者從一些重複簡單的數據處理里解放出來,但是不是開發者不繼續學習的理由啊。

會用框架,那能改框架了么?

能在框架下寫出定製化的組件了么?

能在框架的輔助下完成複雜的業務邏輯處理了么?

能寫得出一個框架了么?

前段開發絕對不能停留在會在框架的輔助下寫點基礎。要學會研究框架思想,實現方式等等,否則框架變了那不就懵逼咯。

而且框架要搭建吧,拋開各種CLI,能把一個項目搭起來也是考驗水平的東西。


什麼東西是本質學什麼

框架的本質就是JS和思想

請學好


JS水平是啥。如果問是否弱化了前端人員編程能力的要求我還能理解……

然後我覺得沒有。

需要的能力還是那些能力,只不過套路上的東西變了一些。


推薦閱讀:

為什麼到2017年7月,知乎上已經很少見到討論angular了?
關於『餓了么的PWA升級實踐』中『採用傳統的頁面跳轉』這一問題?

TAG:前端開發 | React | Vuejs |