做前端如何克服新技術焦慮?

前端變化的太快了,新技術總是層出不窮,以至於老是害怕自己錯過了更為先進的技術。

喜歡react,但看著vue似乎更簡潔和輕量。

喜歡meteor,但又發現了horizon,似乎是它的加強版。

覺得mongodb很好,又出了rethinkdb。

就是昨天還很熱心的東西,今天一下就沒慾望了,更甚至,在遇到問題的時候,老是懷疑自己選的技術棧有問題,老是想「如果選擇了xxx,或許就不用這麼麻煩了...「,請問這種情況該怎麼破呢?

請給出一些指導性原則和意見。


葯我這問題幹啥

題主說的新技術我一個都不會啊

這個圈兒挺怪的

頭半年是怎麼都得搞新技術

不整新技術就是low

後半年這風兒就刮到得基礎好了

貌似新技術就是看看就行了的架勢

基礎不好才是low

這圈裡的個別貨能不能別老揣著明白裝糊塗

動不動就搞偏激

整新聞

其實是並重的

新技術通常是用來解決復用問題

其實也就是說的開發效率工程效率問題

這跟個人技術水平成長關係不大

如同國內合資車廠

引進流水線設備與部件解決的是生產效率問題

但是

如果沒有自主發動機等技術

僅僅有以上這些

只是給外資打工罷了

只能滿足於組裝速度

永遠不可能做成世界品牌

梅賽德斯賓士引擎是不僅可以用於機動車上的

還能用作為戰鬥機引擎

這就是自主技術的通用性

如果你在部件與流水線設備上迷茫

那肯定是你欠缺了其相關知識

「如果選擇了xxx,或許就不用這麼麻煩了...「

等自然而然的換成

「如果用自己寫的xxx,這bug可能就不會有,也就不用看丫是怎麼實現的這麼麻煩了「

那你就可以對流水線設備選擇不迷茫了


做技術要做有沉澱的事。

前幾年 grunt 特火的時候,學會了 grunt,看看現在有 gulp,新的還有 webpack。新技術與技術棧沒有什麼可炫耀的,正如與 N 年我們學到 IE 6 tricky 去到處炫耀一樣自蔽。

不是沒有價值,而是非碼農核心。盲目追新,沒有學習技術的本心和初衷,就很容易被時代淘汰,因為多數人無法比更年輕人一樣有精力去「追新」。

不盲目是怎麼樣的?

React 有哪些優勢,怎麼做到的學其核而不是面。為何 FB 做出來了,學習看待問題與做技術的態度,分析為什麼 webcomponent 沒火起來,x-tag 和polymer 都自己家裡人用?為什麼 hta 落寞。flux 寫起來難嗎?難的是理解與設計,為什麼我們思索不到,看看 redux… Babel 代碼寫得一般般,為何這麼火,要不試試改造後給 PR?jquery 這麼易用上手快,selector 查詢慢?那 sizzle 選擇器設計是否有缺陷?你能 fixed 嗎?less sass 為何出現,是否是 css 缺陷,那 css 又有什麼缺陷?w3c 又如何看的呢?未來發展是怎麼樣?要不自己寫個試試?

那新技術層出不窮,要不要用新技術棧?當然可以,只要你願意去多花時間學習,能弄「懂」。


蟹妖。

表面上看題主是面對新技術在項目中的選型產生的顧慮和迷茫,然而或許題主是對如何建設個人技術棧產生了疑惑吧,私以為根源在於不自知而產生的不自信。

對於這個問題的個人看法

  1. 沒有銀彈

  2. 黑貓白貓和耗子的故事

  3. 沒有空中樓閣

第一點:

參考人月神話,如果沒時間瀏覽,可以圍觀別人的讀書筆記,比如:人月神話-沒有銀彈 (隨手找的,你可以挖掘更好的,或者自己讀一遍)

如果疲於業務,選擇覆蓋多數需求點、易於維護和更替的技術就可以了。

第二點:

耗子在前面跑,黑貓白貓在後面追,然後嘿嘿嘿...(咳,跑偏了)寫代碼不是拍電影,兩個人對打,飛得先拳腳、再刀劍、然後一人倒地快不行了,再拿出槍扣動班機,代表正義消滅罪惡。

所以,你的任務是優先解決關鍵問題。

但是,解決問題的過程中,要妥協什麼和不妥協什麼要想清楚(考慮妥協後的代價)。

第三點:

講個不好笑的笑話,有個人到論壇里求助『請問多少錢可以做一個和淘寶一樣的網站』。

類似阿里巴巴的互聯網公司,如果沒有相對紮實的基礎建設,哪裡來的現在的數據驅動和快速產品迭代呢。

反觀部分學習大廠玩數據驅動的公司,成天到晚伺服器崩來崩去、網路可訪問率低下、數據清洗過濾不完善...在這種情況下做出的決策有多少是相對正確的呢,選擇和建設個人技術棧是類似的。舉個例子:

要做一個聊天應用,你可以只會用WEB前端一套把界面交互搞的絢麗好用,賺人眼球。

也可以考慮在此之上,把相關的工具鏈路都自動化,減少開發過程中的阻塞感,以及提高再次開發當前和同類項目的速度。

如果是創業項目(一切項目都可以這麼看待),你還可以了解這些:

  • 追求性能的一定程度上保障數據安全的客戶端開發

  • 伺服器部署(考慮水平擴展、災備)

  • 伺服器的維護(監控、配置、升級)

  • 客戶端和服務端的通訊(方式、協議、安全性等)

  • 收集整理用戶使用記錄(行為、崩潰),進一步提升軟體質量
  • 甚至是運營等...

或許在閑暇的時候,先想想自己想成為什麼樣的人、想創造什麼、想體驗和經歷什麼樣的職業生涯,再邁出腳步會更妥善一些。(這個答案估計不是一時能想的清楚的)

對上面這句話的答案有一定的輪廓後,大概就知道自己需要什麼樣的技術棧的輪廓了吧。


一般能用gulp解決的問題,grunt都搞的定呀。vue能做的開發,react也沒有做不來的。

新技術焦慮主要是因為老技術還沒學好,覺得繼續學老技術馬上就過時,去學新技術又是熊瞎子掰苞米,葫蘆娃救爺爺。

但是這其中有很多不變的東西,比如MVVM思想,數據的雙向綁定,現代的前端的框架都是以這個為核心的,這一部分知識更迭的速度就很慢,不會超過學習的周期。我學react花了很長時間,後來轉vue就很快,因為很多東西都是類似的,不變的。

同樣道理,gulp搞清楚了怎麼分配一個個task,換到webpack中就是一個個過濾器,很快能上手。前提是把舊技術學好,然後可以事半功倍的學習新技術。

我見過前輩高人,用js平推代碼,編碼速度比我用了框架還要快,簡直是可怕。如果題主還有焦慮,可以去刷一下leecode或者codewars,你可以看到有很多東西是從未變過的。

如果新技術的領域佔了總知識的一大半,當然會有新技術焦慮。什麼時候聽說過演算法的大牛有新技術焦慮?

年輕人多學習一個,沉澱的知識比變化的知識多,自然就不焦慮了。

========================

我又沒說要用js平推業務代碼,比如寫個輪播圖,有人可以直接平推下來,有人就要去查查文檔,或者反覆調試,自然就慢了唄。說的是基本功是不是紮實,可以不看文檔,不出bug,一次把代碼寫對。


謝邀。

新技術自然要學,而且要學得很『快』,目的了解它的本質,以更好的去做架構或優化。

用不用是另一回事,這是一個綜合判斷的過程,是否能解業務問題,遷移成本,學習成本等


告訴你一個秘密:

你是有選擇的,而且選擇錯誤的代價沒有你想像的昂貴。所以重要的是「有」選擇而不是最優選擇,多少人的生命浪費在後者上。

假如你選擇了MongoDB,但後來發現RethinkDB是更好的方案,或者MongoDB被社區徹底拋棄了,不要驚慌,我的少年,80%以上的MongoDB或者資料庫使用的知識,是可以遷移到RethinkDB或者什麼DB的。

假如你現在決定學習React,學到中間發現Vue更適合手頭的項目,不要驚慌,我的少年,你接觸到的React里使用的概念,大多數是可以比較平滑地遷移到學習Vue中的,也許語法上會有差異,但這很難成為問題。學過React以後哪怕放棄React學Vue,也會比不學容易不少。

你真正要避免的。

因為看到Vue,所以React遲遲不敢接觸;

因為不能決定到底哪個好,所以哪個都沒有嘗試,連基本的tutorial都沒有去做。

這叫 Analysis Paralysis。這是最糟糕的情況,搞得自己精疲力竭,腦袋裡千迴百轉,但最終什麼都沒有試,連浪費時間做不合適的選擇都沒有做。

如果你覺得要想好再做,搞技術你會很痛苦的,因為以後不斷面臨這種選擇,你既不了解A,也不了解B,卻想什麼都不試就做決定。

因為根本就沒有標準答案,自己試一試是最快最好的方式。


===============補充應該寫在前面,才有人看-2016-06-08=========================

回頭看了一下問題,發現我的回答好像有一點點偏題啦哈哈哈_(:з」∠)_ =3=3 審題不明確扣10分

做前端如何克服新技術焦慮?

給出一些指導性原則和意見。

先來看一張圖,其實題主陷入的困境無非是下面這張圖所描述的死鎖狀態。由於死鎖而產生了焦慮,並且惡性循環。

所以回到主題如何克服,根本問題是如何打破這個死鎖狀態,很簡單,其實上圖每個節點都可以做出對應的決策 。

圖一看就懂,無非是不要一根筋去追求技術棧的量,出現新技術要帶著理智的眼光去評價,不要別人說好自己就覺得好,什麼東西都是自己用過才知道合不合適。

合理地學習,優劣互辨,把握好自己的心態,那就能真正走出這個死鎖了。

這就是全部的指導性原則和意見了。

===============補充應該寫在前面,才有人看-2016-06-08=========================

更正一下,mongodb和前端沒有半毛錢關係哦。

技術選型這個問題其實很簡單:不選最好的,選最合適的!

下面簡單說一下我經歷過的技術選型場景

公司的移動應用項目要開發WebApp,基本上是把APP的功能復刻了一遍。

伺服器方面與APP伺服器共用,採用RESTful API作為網路架構,前端採用Angular.js作為邏輯框架,angular-route做前端路由,mui做前端UI框架。

公司要開發一個活動抽獎頁面。

伺服器方面選用PHP,資料庫採用MySQL,前端採用Vue.js做數據綁定。

項目需要增加數據統計

app伺服器本身採用nodejs開發,統計方面則選用python來進行,統計數據可以存到mongodb,前端使用highcharts來展示數據。

項目需要管理系統

前端採用React.js進行組件化開發,採用bootstrap作為UI框架。

上述四個場景,分別代表四種類型的技術選型。

  1. 應用型:這種類型項目特點是功能繁雜,系統較為龐大,還要較好的交互體驗。為了減少開發周期,和APP共用介面,伺服器開發效率大大提升;前端採用angular+route可以很好地組織前端結構;mui則提供了仿原生的UI組件和交互組件,進一步減少開發成本。
  2. 活動型:這種類型項目比較簡單,只有一個或兩個頁面,介面較少,完全可以採用PHP進行快速開發,前端也可以採用輕量級的Vue做數據綁定。
  3. 計算型:這種類型涉及到計算效率,所以採用Python來進行計算邏輯的編寫,因為統計數據的靈活性採用mongodb這種schemaless的存儲結構,前端主要是展示圖表,所以採用highchart作為數據展示框架再好不過。
  4. 管理型:這種類型因為功能的服用情況非常多,很多代碼是可以在多個地方復用的,所以採用React來進行組件式開發,最後只要對組件進行拼搭就可以了;採用bootstrap是因為管理系統對視覺的要求沒有客戶端高,可以採用比較高效的方式來處理。

總結:所以不要怕新技術層出不窮,每一門技術都是有用戶之地的。錯不錯過也無所謂,人就是個人,有能力的限制,不可能什麼都必須去了解。重要的是,對任何技術的熱情不要是三分鐘熱度如果是因為這個原因最後什麼都沒學成那才是悔之晚矣。

在遇到問題的時候,老是懷疑自己選的技術棧有問題,老是想「如果選擇了xxx,或許就不用這麼麻煩了...「

對於這個問題,很簡單。如果當初選的是xxx,你同樣會老是想『如果選擇了yyy,或許就不用這麼麻煩了...』 因為每個技術都是各有優劣的,選型不是要選十全十美,而是要選最合適合理的搭配。


提升自己的硬實力,學點真本事,就就不會人云亦云,莫名焦慮了!


其實我一點也不憂慮,有段時間也是聽到別人說什麼就去整什麼,後來發現其實只要js基礎好,英語好(能看懂API),跟著官網跑跑demo,其實沒什麼難的啊。

所以還是打好基礎。

javascript的prototype、constructor、作用域、閉包、設計模式.....都弄明白了嗎

什麼都不要圖新,如同建築,底盤扎得老實,上面才能蓋高樓。


說真的,沒啥好焦慮的。

前端框架無非MVVM和MVC,

資料庫無非是關係型和非關係型。

新技術搗鼓來搗鼓去,除了API層面不一樣,裡面的運作原理都是差不多的。

就比如你學個webpack,看下官方說的code splitting,大致也知道了這貨是幹嘛的。

比如框架層面比較火的react和vue,無非是不同的整合html/css/JS的解決方案,看下文檔和demo,也是分分鐘上手的事情呀。

依我之見,在使用新技術的時候,著眼於學習作者解決問題的思路和設計框架的模式比較重要。

對於項目早期的技術選型,這個確實是需要經驗和理解的,不是一般程序員能夠完全hold住的事情。

對於題主的問題,我覺得基本的原則就是要對技術多學習多思考,再選擇能在適應業務需求的基礎上具備高維護性的技術框架即可


新技術要看透本質, 看看新技術究竟解決了什麼痛點, 是否對現有的東西有革新般的改變, 學習思想最重要...不要光看個樣子...


謝某同事口頭邀請

小白首答

我是從去年無基礎開始學前端的

師父是我男朋友

到現在學了剛滿一年

依然是個戰五渣

至於樓主問的那些技術

也只限於聽過和沒聽過

但是我還是在寫前端啊

只會用html5,less簡單的jquery 和angular js

關於焦慮這件事

我從開始學這個的時候就開始了

只不過和題主的方向不一樣

我是焦慮的其它方面

跑題了

跑回來

所以對於題主的提問

因為害怕新技術層出不窮

自己跟不上新技術

我的建議是

穩紮穩打

前端最基本的是html5,css,js

如果你基本功的水平已經到了寫標籤時,能夠使用對應的語義化標籤,而不是一個div 標籤從頭到尾;能夠只用css3就能做出酷炫的頁面效果(比如動畫,延時),而不加任何js(我說的僅僅是效果,不包含交互)

如果你的水平這麼厲害了,那就當我什麼也沒說咯~ 如果還沒到家的話,建議先不要看那麼多複雜的新奇的技術,乖乖的學習怎麼把標籤和css 用到出神入化吧。


多玩兩局Dota。

過了兩年再去看。


你需要有你自己的風格和理解。

編程界之所以有面向對象面向函數等等,就是那些先驅有總結自己的編程風格而來的,最適合自己的編程風格可能就是受影響而介於一些編程風格之間。

不倫是react還是angular,都是那些老司機遵循某些編程風格編程思想而搞出的一套套方案、工具。

那麼新技術出來的是就理解、學習這些新技術的思想核心。如果適合自己,那就可以深入,不適合,就捨棄。


為何邀我回答老問題吶?

其實如果心裡有壓力,換Python。歲月靜好,Python如歌。


謝邀,好久了。

底子紮實一些,看什麼技術都不是新技術,新瓶舊酒的關係。

當然,以上是我在裝逼,我在努力達到這個境界 - -


技術焦慮是很常見的事情,這在前端更為常見。

有幸和一些前端大牛交流過,發現他們的眼界非常開闊,同時也緊跟著技術前沿。交流中,我感受比較深刻的在於,

你可以隨時關注最新的技術,但是你需要有自己的判斷。如果你覺得這個技術可以為你所用,那麼花些時間來研究。如果你覺得這個技術你並不太認同,那麼就簡單看看社區的issue,了解一下他們的思想是什麼。

此外,也可以參加一些講座。對於目前前端的趨勢進行一定的了解。

就拿 @尤雨溪 做個比方,如果你參加過他的講座。你會發現,作為vue的作者,他對於同類型的前端框架也非常了解。從他的講座里,你可以很方便地了解各個框架的橫向對比,幫助你將來的技術選型。

對於新技術的出現,總是為了解決目前遇到的某個問題。如果這正是你同樣遇到的問題,那麼不妨多花些時間來學習一下(同時記住規劃你所擁有的時間來進行技術選型)。如果不是,那麼不妨當做閑暇時候的點心嘗嘗。切忌在不熟悉的情況下上新技術,你會發現把項目變成為了學習、試錯的過程,導致開發中隨著你的知識不斷完備回頭髮現自己給自己埋了不少的坑。

把對新技術的研究作為愛好而不要當做自己的壓力就好~


戒浮躁,定乾坤。


一個新的框架或者一個新軟體一個新函數庫就可以被稱之為是一種新技術嗎??

學好英語,多上github,終有一日你會發現,不過是代碼的一種組織方式,或性能優化,或維護優化,或開發效率優化,核心技術還是那些。(′⊙ω⊙`)


給自己設定個目標,把 css2/3 ecma3/5 html4/5 的規範學得七七八八的時候,再深入學新技術。 在這以前,對新技術達到了解的程度就夠了。

現在我大概學了六七分了,也就是常用規範做了大致的閱讀和理解。但對於應用架構還沒有太過深入的研究,而且未來一年也不打算深入,接下來準備再搞一年的前端工程化。在目前前端領域來看,架構問題還沒有太明朗的前景,所以做點技術儲備即可。


推薦閱讀:

asp.net mvc 項目中怎麼用react redux,vue 等前端框架?
前端新人的迷茫?
React Native和React有啥區別?
單頁面應用,TAB選項卡太多,頁面邏輯是糅合在一起還是重新分路由?
為何需要Angularjs、backbonejs、reactjs?

TAG:前端開發 | JavaScript | Meteor | React | Vuejs |