割裂的前端工程師:預測前端的2017

有一天,我們組內的一個小伙伴突然問我,你知道有一個叫重構工程師的崗位?這是干什么的?(知乎上有關于重構工程師討論https://www.zhihu.com/question/19597859)

這個問題引發了我對前端領域發展的思考,所以我來梳理下前端領域的發展過程,順便小小地預測下2017年的趨勢。

神說,要有光,就有了光

自1991年蒂姆·伯納斯-李公開提及HTML描述,到1999年W3C發布HTML4期間,寫網頁是為了更好地交流彼此的想法,是為了能夠維護自己的網頁。

這個時期,各路大神也是八仙過海各顯神通,甚至發明了PHP(這個世界最好的語言)。這時并沒有一個所謂的前端開發崗位,大家都是軟件工程師

當然這個時代也是神人輩出的時代,太多現在互聯網或者說整個IT行業的概念和雛形在這個時期形成。Google網站正式啟用,個人PC開始慢慢普及。

神稱空氣為天

O'Reilly Media、Battelle和MediaLive在2004年10月引導了第一個Web 2.0大會,Web 2.0時代開啟。

Blog、Wiki、RSS等各種個人網站開始進入大家的視野。同時,豆瓣、天涯這些符合2.0時代的產物開始在國內大行其道。我們有了第一波注重Web前端的軟件開發師。

同一時刻,美國誕生了FaceBook具有跨時代的產物。2005年,校內網出現,前端們開始活躍起來。2006年8月,jQuery的第一個版本發布。

神稱旱地為地,稱水的聚處為海

之后的幾年間,前端基本都是圍繞著各種類庫如Mootools、Underscored、Prototype、Dojo,jQuery ,YUI開發頁面。各大類庫也是相互吸收優點,不斷完善自身,但是本質沒有太多變化

與此同時,在我們看不到的背后,瀏覽器第二次大戰打響,V8引擎開始大放異彩,Web標準也在推動ECMAScript 5.0進化著。Node發布了,意味著我們前端的領域擴大了,伸手到服務端了。

智能手機開始普及,移動端大浪潮流勢不可擋,Web前端們開始為了移動端開發各種類庫了Sencha Touch,Zepto.js,jQuery Mobile,HTML5概念火熱了起來,各種網頁小游戲層出不窮,和Flash的爭斗也到了水火不容的地步,Twitter 也推出了 Bootstrap這個引領風騷的CSS工具包。

隨著系統硬件的提升,V8引擎性能的提升,整個網頁的性能極大提高,大家開始紛紛開發出復雜的Web頁面來,這種需求開始催生了前端們對開發的工程化思考,首當其沖的就是模塊化加載的問題,AMD、CMD、UMD 登上舞臺,起衍生的產物SeaJS,RequireJS開始劃分地盤。

這個時代還是服務端渲染為王的時代,包括很多模塊或者組件上的拼接都是在服務端完成的,但同時也開啟jQuery + RequireJS + Template開發復雜頁面的模式。(這個時間段,出現了重構工程師和JS工程師的劃分。)

管理晝夜,分別明暗

2012年之后,隨著W3C規范和標準進一步推動,大家對Web頁面復雜度進一步的加劇,人們不再滿足于jQuery面條式的開發,出現了許多用于簡化客戶端開發的框架。例如Backbone、Ember、AngularJS、Vue、Alavon、Knockout、React等,各種各樣的MV*框架。

這是一個群雄割據的時代,如此多的框架涌出,每個開發者根據自己的喜好、業務的需求來選擇不同框架,進而完成目標。

Node.js開始崛起,Express、Koa框架開始使用到各種生產項目中。PM2的服務管理,為企業解決了監控和穩定問題。同時,阿里開始探索NodeJS中間層的開發道路,連續發聲,提供前后端分離解決方案。

神說,水要多多滋生有生命的物

微信這個社交龐然大物已然崛起,微信公眾號的玩法,讓前端崗位開始火熱了起來,也開始帶來了Web和Native的爭端。

15年,Facebook 在 React.js Conf 2015 大會上推出了基于 JavaScript 的開源框架 React Native,一舉將React推上了一個新的高度,learn once ,write everywhere。這一年是屬于React的年份。

同時,構建工具也在不停的迭代,Grunt的輝煌已去,Gulp并未在王座上久呆,Webpack的風暴就席卷而來。

16年,Webpack已經成為了前端打包構建的主流,Vue強勢崛起,Ng2完成發布。前端在主流開發上基本形成了三國時代(React、Vue、Ng)。與此同時,移動端也形成了以混合開發為主的方式,Native嵌入WebView頁面。

神就照著自己形象造人——細分或者割裂

上面回憶了一下前端大概的發展歷程,下面來說說自己對17年前端發展的一些預測。

隨著業務的不同,每個團隊在前端技術點開始有所分化:

重型SPA頁面

Hybrid方式的Web頁面

活動頁面

游戲等其他

重型SPA頁面 —— Teambition

重型的SPA頁面,業務功能極其復雜,使用Vue,React,Angular這種MVVM的框架后,在開發過程中,組件必然越來越多,父子組件之間的通信,子組件之間的通信頻率都會大大增加。如何管理這些組件之間的數據流動就會成為這類WebApp的最大難點。

從頁面的加載來說,SPA可以依靠首次加載的Loading動畫,來掩蓋一些頁面加載性能的問題(TB我這里加載一般在5S左右),很多懶加載和延遲加載之類的也是不需要做。因為相關的數據后面都需要用到,也就不存在是否會使用的問題。

從最近Rx.js的star數,我們也能看出來,大家也越來越關心數據管理的問題,本地的數據管理只是一個方面,還會涉及到多個用戶數據同步的問題,也就是服務端和客戶端數據同步問題,如和及時正確的同步數據。

及時正確同步數據這個概念指的是: 多人操作一個任務時,兩個人都在修改一個任務時,容易造成數據覆蓋。A剛修改完,B過幾秒也修改了,因為同步不及時,B不知道A修改了,結果B新修改的數據覆蓋了A的修改。所以想要減少類似的錯誤,就必須要能保證及時正確的同步數據。

既然數據和請求如此多,那么就肯定要利用好本地的緩存和各種存儲了,LocalStorage,SessionStorage的都會使用上。

如此多的業務和組件,必然對內存上會造成壓力,如何管理好內存也是一門學問。

相關的可以看徐飛的文章https://github.com/xufei/blog/issues/35。

Hybrid方式的Web頁面 —— 現在大多數App的主流

Hybrid方式的開發目前還是移動端的主流,這種Web頁面的特點是業務并不復雜,大多是展示信息為主,再加上一些操作按鈕,需要解決的問題,在于很多時候要和Native來通信,而且Android的WebView有各種各樣的國產廠商問題也是很難以解決,這方面微信做的不錯,直接搞了一個自己的瀏覽器來統一底層的支持。

對于jsbridge的實現,各個公司有不同的實現方案,主要還是要看Native的開發怎么來定義bridge的方案,以我自己開發的經驗來看,有這么幾個點需要解決:

用戶驗證問題,怎么來確認Native的用戶身份,是用原來Web網站常用的session還是使用Native比較常用的token,但是不管用哪種,都需要Native幫忙來注入標識。

AJAXAJAX請求問題,如果使用一個URL的形式來嵌入,可以獨自發送AJAX請求沒有任何問題,但是如果使用HTML文本,直接WebView渲染的方式,就類似PC上,文件夾打開HTML文件一樣,AJAX請求發送不出去,需要Native幫忙做bridge來調用。

溝通成本問題,因為和原來PC端相比,多了參與方,所以排查問題就更加麻煩了,這個還是主要看整體App的架構怎么設計了。

性能問題,怎么說呢,不是每個App的開發人員都很厲害,那么如果Native的代碼有問題,WebView出錯的概率就會變高,比如Css3的動畫,容易引起崩潰,內存占有率過高等等。

所以,對于這個方向的Web前端的開發人員來說,如果會Native開發的經驗更加如魚得水。

活動頁面 —— 比如來自宇宙的邀請函

這類活動頁面,主要就是設計和動畫上效果炫酷,吸人眼球,震撼人心,基本出來一個精彩的活動頁面,都能在朋友圈掀起一波浪潮。技術上以WebGL為主,一般使用Three.js,渲染canvas來展示各種動畫和視覺效果。

這個方向的前端會更加關注,瀏覽器的兼容,性能,設計出來的效果,動畫的流暢度,體驗等等。主要兼容的微信的瀏覽器,因為要在朋友圈來營銷,總體來說,會偏設計以及動畫些。

游戲等其他 —— H5小游戲,數據可視化

當時風靡國內的各種H5小游戲,特別多,基本是用CreateJs(http://createjs.com/)來制作的多,接觸不多,不多評論。

HTML5游戲引擎深度測評可以參閱http://www.lxweimin.com/p/0469cd7b1711。

隨著大數據時代的來臨,前端領域各種數據可視化的庫也是層出不窮,D3,Highcharts,國內的Echarts都是這個領域的佼佼者。

切換領域

其實還有一個領域,就是通過Nodejs,學習服務端的各種知識,切換到服務端領域去。

未來

上面的我所提到的細分(或者說是割裂——比較有噱頭),自我感覺,已經在慢慢展現出一些趨勢了,不知道大家有木有感覺到,比如徐飛就會更加擅長TB這種重型業務流派,而手淘的人就會比較關注Hybrid的流派,甚至自己來搞Weex這種JS-Native開發的框架。當然大部分開發人員還是可能都會做,沒有那么明顯的傾向,但隨著公司的業務的轉變和公司重點資源的傾斜,很多開發人員還是會慢慢有所區分。

個人認為這種細分其實對我們前端更加有利的,第一,這表現出前端整個領域發展比較迅速,各方面都有參與到,沒有和時代脫節。第二,有各種細分的領域,大家可以做到一專多精,不用害怕失業的煩惱。因為每一個方向都可以做的很深,動力很足。第三,利于交流,各種不同分支的人,可以拿出自己特長的技術來相互交流,取長補短,構建更加系統的知識網絡。

(以上只是個人見解,如有雷同,只能說英雄所見略同)

地址:https://zhuanlan.zhihu.com/p/23858051。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,501評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,673評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,610評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,939評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,668評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,004評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,001評論 3 449
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,173評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,705評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,426評論 3 359
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,656評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,139評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,833評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,247評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,580評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,371評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,621評論 2 380

推薦閱讀更多精彩內容