近幾年前端技術盤點以及 2016 年技術發展方向

jopen 8年前發布 | 58K 次閱讀

Web 發展了幾十個春秋,風起云涌,千變萬化。我很慶幸自己沒有完整地經歷過這些年頭,而是站在前人的肩膀上行走。Web 技術發展的速度讓人感覺那幾乎不是繼承式的迭代,而是一次又一次的變革,一次又一次的創造。這幾年的前端,更為之甚!

我從 12 年底開始接觸前端,12 年之前的前端發展情況只能從上一輩的筆觸中領會。本文會盤點從 09 年開始到 15 年間前端技術的革新,同時也會從多個角度,解讀近幾年前端技術發展的潛在因素,其中穿插了若干對前端演進的拙見,難免會有錯誤和疏漏,望讀者可以補充和斧正。

那些年,一度追捧,一度放棄

下面,花一些篇幅簡單回顧下 09 年到 15 年前端的發展歷程。

09 年,基礎類庫完善,尋求突破

09 年之前,JavaScript 還處于對自身語言的完善過程中,而到了 09 年,JavaScript 類庫已經頗為成熟,jQuery/Prototype/Script.aculo.us/Dojo 等都已經發布了好幾個 stable 版本,各大類庫也是相互吸收優點,不斷完善并提高自身性能,然而功能上已經沒有太多增加的勢頭。部分框架開始了思想上的轉變,更加注重前端開發的組織和結構,條理性強了很多,如 YUI,Dojo 等。

從 ECMAScript 規范的爭執,開啟了瀏覽器引擎大戰,各大廠商也趁機瓜分 IE6 份額,Chrome 和 Firefox 在這場戰役中取得小勝,V8 也敲響了前端的大門。為了迎合市場的激烈競爭,IE 開始了升級之旅,09 年初發布 IE8,全面兼容 CSS2.1。

而此時,Node.js 和 3G Mobile 這兩只巨獸開始浮出水面,Web 標準也開始向 HTML5、ECMAScript5.0 靠攏。

10 年,Web2.0 深入人心,開始性能挑戰

毫無疑問,這一年,各大巨頭都看清了 HTML5 是 web 發展的未來,在保留原來前端技術的狀態下,都簇擁著拉扯 HTML5 的裙擺。富客戶端應用也在這一年蓬勃生長,ExtJS/Dojo 搖身變為企業級框架,各類組件化概念和產品如約而至。

延續著 09 年的變化,10 年的前端顯得頗為沉寂,然而在標準的運用和推動上,各大廠商也是十分賣力。IE 9 出來了預覽第三版,iPhone 的 Safari 已經能夠支持眾多 HTML5 內容:Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database 等。

W3C 宣布成立 Web 性能工作組,Google 和 Mozilla 紛紛推出應用商店,瀏覽器調試工具也豐富了起來,人們開始更多地關注開發體驗和性能問題。

11 年,HTML5 抗大旗,Flash 堪憂

2011 年 HTML5 的技術發展和推廣都向前邁進了一大步,語義明確的標簽體系、簡潔明了的富媒體支持、本地數據的儲存技術、canvas 等等各類技術被廣泛應用。這一年,很多 web 開發者也面臨一項技術的抉擇,HTML5 or Flash?從 Flash Player 11.1 開始,Adobe 不再繼續開發面向移動設備瀏覽器的 Flash 插件,積極投身于 HTML5,這意味著 Flash 技術的凋零。

這一年,HTML5 游戲火爆到了一個高潮,他的低門檻和高收益讓很多開發者眼紅,正因如此,移動端開發工具和調試工具也日益成熟。jQuery 已經成為大小公司日常開發的標配,成千上萬的 JQ 插件讓網頁開發變得尤為輕松,而隨之而來的也是頁面的臃腫和性能調優的深入探索。

Node.js 已經悄然崛起,在 github 上的訪問量已經超過了 Rails,國內的云應用開始嘗試使用 Node.js,Node.js 相關工具也紛紛出來。

12 年,響應式開發,工程化推進

隨著硬件技術的發展,各手機廠商又開始騷動起來,為了占有更多的市場,不斷提高產品的性價比,體驗也得到了不斷的優化。借著先前兩年 HTML5 刮起的東風,移動端上的 web 開發也顫抖了起來。移動端的開發挑戰不亞于 PC 上對多個瀏覽器的支持,這一年,萌生了眾多移動端框架,如 Sencha Touch/Zepto.js/JQ Mobile 等,相對 PC 端框架,它們更加輕便。

而移動端的崛起,帶來了許多終端開發難題:多終端適配,多分辨率適配,遠程調試等等,而隨著這些難題一個個被解決,移動端生長的勢頭變得更加強盛。此時 推ter 也推出了 Bootstrap, 這個前端開發工具包不僅方便了前端,也方便了后端同學,它的出現讓快速建站更加簡單。

編程思想的切換,迎來了 CoffeeScript 和 TypeScript,這兩個預處理語言的出現又為 JavaScript 引來了不少其他方向轉型過來的開發者。JavaScript 的兄弟 Node.js,也在命令行領域開拓了一片不小的疆域,甚至有動搖 Perl 和 Ruby 地位的趨勢。

在前端工程化上,幾個派系相互爭斗,產出了 AMD、CMD、KMD 等規范,也衍生了 SeaJS、RequireJS 等模塊化工具。前端在這一年很有跳躍感。

13 年,爆發式增長,百花齊放

規范和標準上有不少產出。Web Components 的出現給前端開發開辟了新思路;WebDriver 規范的出來推動了自動化測試的進程,ECMAScript 6 的規范草案落地,Webapp 工作小組在這一年也是相當活躍。

Chrome 瀏覽器在這一年也有了很大的突破,開始支持 SPDY,使用 Blink 取代 webkit 作為 Chromium 的新渲染引擎,Chrome DevTools 的調試體驗大幅度提升。這一年中,Chrome 連同其他瀏覽器廠商快速推動了各項草案規范的實現。

語言能力上依舊在增強,并且從 JS 開始擴散到 CSS,出現了 LESS、SASS 和 Stylus 等預處理語言,Web 開發變得更加緊湊。

而在無線端,應用不再局限于 Webapp,由于流暢度、性能等方面不能滿足用戶體驗的需求,各大公司開始轉向 Native 方向的研究,進而出現了 Hybrid 和 PhoneGap 的繁榮,它們為 JS 調用了提供更多的設備 API。

Node.js 大放異彩,很多公司在生產環境中使用 Node.js,同時也出現了諸如 Express、Meteor 等小巧的快速搭建 Node.js Server 的應用框架。

各瀏覽器的調試也是種類繁多、功能豐富,PhantomJS 在自動化測試上開始取代 Selenium,出現了眾多的遠程調試方案和工具。

前端工程化開始普及,各公司開始推出自己的前端集成開發解決方案。

14 年,移動端的崛起,HTML5 和 ES6 落地

HTML5 正式定稿,這意味著,web page 正式演變為 web application。ES6 華麗麗走進前端,走的很穩重,它的 Module/Class 等特性已經完全讓這們語言具備了開發大型應用的能力。

大而厚的基礎庫難以滿足靈活場景,Mobile 要求極致體驗,MV* 庫鋪卷而來,如 avalon/angular/knockout 等。

Web Components 跨終端組件快速發展,移動端開發迎來一次升華。Node.js 前后端分離的流行,中間層的出現改變了前后端的合作模式。

2014 是顛覆式的一年,前端發展在這一年開始形成了一個短暫的穩定格局。

15 年,觀念的轉變,步入前端工業化生產

今年格外引人注目的框架是,類 React。非死book 在 React.js Conf 2015 大會上推出了基于 JavaScript 的開源框架 React Native,它結合了 Web 應用和 Native 應用的優勢,可以使用 JavaScript 來開發 iOS 和 Android 原生應用。在 JavaScript 中用 React 抽象操作系統原生的 UI 組件,代替 DOM 元素來渲染等。敲一次代碼,能夠運行在多個平臺上,其優勢可見一斑。除了 React ,還有手機淘寶推出的 Weex 框架,它吸收了 vue.js 的編程精華,編程風格更加簡約。

在眾多構建工具中,如今瀟灑存活的并不多。體驗完 grunt 和 browserify 后,gulp 順勢而至,爾后又出現了 webpack、jspm 等。而包管理工具,經歷了 components、bower、spm 后,npm 開始主導整個市場。

Node.js 的應用已經鋪天蓋地,各大公司前端都把 Node.js 作為分離前后端的主要手段,并且在測試、監控等方面沉淀了大量內容。不過,這個市場是很苛刻的,Node.js 的性能難以達到 C/C++ 的水平,那么接下來要做的就是要提升性能,至少得接近 C/C++。

Web 規范和標準

最開始,我們看到的 JavaScript 還只是一個簡單的腳本語言,配合著 AJAX,在網頁上翻騰了好幾個年頭。隨著互聯網趨勢越來越明顯,互聯網業務量和業務復雜度不斷增加,很多網頁變得相當復雜,如讓我們震驚了好一會兒的 Gmail,交互復雜,體驗優良。為了更好的多人協作,代碼中的 Utils 庫越來越大,在這些庫中,基礎部分更多的是對 JavaScript 語言本身的拓展,比如給 String 加一個 repeat 函數,再加一個 trim 函數,再加一個 endWith 函數等等。

復雜的業務中會經常看到一層又一層的回調處理,回調的嵌套讓代碼的可讀性變的很差,而且很難將多個異步并行處理。為了改變這種編程范式,我們做了很多的思考,使用事件監聽,使用各種手段拉直回調,平坦地調用。

慢慢的,如果你在關注 W3C 小組的動向,會發現,那些被認可的,并且被廣泛重復定義的東西,都被納入了標準。最開始的 jQuery/prototype,前者主要是對瀏覽器做兼容處理,讓開發者不再把精力放到瀏覽器的差異上;后者是對語言本身的拓展,對 JavaScript 各種類型做拓展,并且提供了一套拓展任何對象的功能集。而現在的開發,我們很大程度上不再依托這些類庫。規范和標準已經把這些差異都統一了,String 中自帶了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函數,Array 自帶了 from/forEach/of/keys/values/find/findIndex 函數…

規范的標準是為了讓開發者得到更好的編程體驗,編程不是目標,目標是將編程生產力轉化成實際效益,越少的阻礙對開發者越有利。各瀏覽器廠商當然也認識到了這一點,他們不斷地提升自己產品的體驗,將標準中的新特性都融合進去,比如 ES6 中的 Promise/Generator/Class/Module 等等。在這些內容普及之前,我們不需要加入 jQuery/prototype 這些「不純粹」的東西,而是添加兩個 shim 和 polyfill,如 es5-shim,html5shiv 等等。待到山花爛漫時,再輕松刪掉這些補丁程序。

這兩年工程化很熱,W3C 小組也看到了,這就是市場的需求,為了完成一個大型應用的編程,就必須模塊化、組件化,于是在規范中也出現了 Module & Module Loader;Node.js 的到來,讓很多前端工程師開始接觸數據庫操作,面對巨量的異步,我們忍氣吞聲寫了無數的回調地獄,盡管使用了很多 Promise 相關的操作,程序結構依然松散難以閱讀,于是規范中也開始出現了 async/await 等對 Generator 的上層封裝。文字已經不能滿足當代人的溝通需求,音視頻等富媒體傳輸走進了我們的生活,于是規范中也出來了 WebRTC/WebAudio 等規范。

只要規范出來了,后續市面上就會根據規范來實現一套 shiv,這些 shiv 提供了同樣的 API,提供了同樣的編程體驗。當瀏覽器自我進化完成之后,這些 shiv 也將成為歷史,被開發者遺棄在代碼的注釋之中。這些都是規范和標準的魅力,它的存在,就是讓開發者把精力投入到自己的業務之中,編程和范式的工作交給它。

這里 可以看到,W3C 各個小組最近都在干啥。標準不能囊括一切。

生態的自我完善和自我拓展

技術的更迭過于頻繁,我們能夠清晰地看到,很多人還在用更迭前一波甚至是前好幾波的產品。

當年的 IE6,在戰場上鏖戰了 10 多個年頭,依然屹立不到,而現在它在市面上依然有百分之一左右的占有率,這種小強精神不得不讓人肅然起敬。“只要用戶在,我們就得追隨”,這可能是很多公司的服務理念,因為用戶就是潛在的利潤。正是因為這種服務理念,成就了 IE6 一個又一個的 5 年!然而低本版的 IE 已經不僅僅是被前端從業人員抵制和排斥了,網絡安全、網絡運維、QA 等等,各個技術崗位的人員都開始對他不屑,它的存在對工作效率、對安全、對很多方面產生了極為不良的影響,甚至影響到一些核心內容的推廣,所以 2016 將是低版本 IE 消亡的一年,我也呼吁業界所有的朋友舉起義旗反抗起來!

慶幸的是,也有人開始吃螃蟹了。從支付寶到天貓到淘寶,阿里巴巴在很多業務上已經主(bei)動(bi)地放棄了對 IE6 和 IE7 的支持,甚至在統一接入層直接做了 302 跳轉,提示用戶更新瀏覽器或者引導流量到無線端。這是一個好的開始,我們期望這也是業界達成共識的開始!

HTTP 協議,從 1.0 快速過度到了 1.1,整個互聯網的上層建筑變的十分穩固。當然,我也了解到依然有很多產品還是保持了 1.0 的狀態,據說電信公司的很多產品就是使用 HTTP/1.0 進行通訊,這無疑讓人驚愕。為了追求更高的效率,減少網絡傳輸中的無效流量,W3C 工作組對 HTTP 協議也做了重新的定義,SPDY 就是 13 年比較火熱的一個話題,Firefox 和 Chrome 都陸續開始支持 SPDY,后來在 SPDY 的基礎上做了升級,正式定義為 HTTP/2.0,它的一個很大特點就是多路復用,這個小小的特點改變了我們前端編程的很多優化模式,比如

  • 域名不是越多越好,為了能夠充分利用瀏覽器的連接數,我們給 JS 和 CSS 開一個域名,給 img 開好幾個域名,網頁打開的時候,恰到好處的利用瀏覽器的連接數上限限制。HTTP/2.0 的多路復用,就是可以在一個 HTTP 請求中進行多個資源的傳輸,如果域名散列,反而不能利用這個特性
  • 資源合并沒有任何優勢,以前的資源合并是為了減少請求數以節約建立 TCP 鏈接的網絡開銷和頭部傳輸的流量開銷,而在 HTTP/2.0 中,一個 HTTP 請求上完全可以把所有的資源全部推送過來,如果合并了資源,反而不能良好運用瀏覽器對資源的緩存。

當然,除了多路復用,還有很多其他的優化,比如傳輸的數據為二進制流,HEAD 頭會被壓縮處理,服務器可以向客戶端推送內容等。在這個技術水平指數式增長的年代,我相信以后的革新不會比消滅 IE6 痛苦。

模塊加載上,經過了各派系的爭論之后,流傳下來幾個不錯的產品 SeaJS、RequireJS 等,那么那個模塊加載器將成為工具平臺中短暫的終點呢?似乎這些都不是。當我們按照規范中的方式進行模塊定義,按照規范中的方式加載定義的模塊時,加載這個流程就顯得不那么重要了,因為這些事情最后都會變成 shiv/polyfill 的事情,最終會變成瀏覽器的固有屬性。

當一個東西在社區中被暴力追捧的時候,會有很多衍生的產品出來,當這些衍生物根深蒂固時,可能又會出現一個更加原生更加符合開發習慣的東西出來。就像 jQuery,我們為它編寫的插件不計其數,而在工程化的需求沖擊下,它卻顯得那么的弱不禁風,因為它關注的點和當前的發展態勢不太吻合,僅此而已。

Mobile 的發展驅動著戰場的轉移

記得當年拿著 Nokia5230 學完了 HTML 和 JavaScript 的入門,那屏幕尺寸也就是三個手指的寬度,緊緊攥在手里看著頁面混排效果極差的網頁文檔。

現如今,iPhone 都出到 6s 了,一個版本一個尺寸,而且尺寸越來越大,還有各種寬高不一的 Android 機器,種類繁多。以前的觸屏是電阻式,只支持單點觸碰;而現在電容式的觸屏精度更高,還支持多指觸控,這如絲般順滑的體驗在三四年前是完全體會不到的。曾經手機開一個程序久了就會卡,動不動還會自動重啟;而現在的手機開一堆程序,完全無感知,這就是硬件發展前后的差異。

手機已經成為了人們生活中不可或缺的一部分,甚至成為了一些人身體的一部分,淘寶今年雙十一的數據顯示,國內移動端的消費比例已經遠遠超過了 PC 端,占比 68%。面對龐大的用戶,我們的技術是否做好了充足的準備,這里還得打一個問好。

PC 上那一套經驗不是直接搬到移動端就可以使用了,在移動端還需要解決更多的問題:

  • 多分辨率問題,這里涉及到了響應式設計和前端響應式技術
  • 不同網絡環境的網頁加載優化問題,2g/3g/4g/wifi
  • 手指交互帶來的一系列體驗問題
  • 為了提升用戶體驗,將 Web Native 化 —— 類 React 技術帶來的一系列問題
  • 遠程調試問題
  • 移動安全問題等等

上面提到的問題很多已經有了優秀的解決方案,當然也有很多未提及的。WebApp 的性能、流暢度和穩定性遠遠不如原生應用,同時它也無法良好地運用設備提供的原生功能,這些都是大家轉投 Native 的原因。

端的融合

不同分辨率的手機,不同物理尺寸的終端,為了保持良好的視覺體驗和用戶體驗,我們不得不為每一個尺寸寫一份 Media Query 代碼,那么對應的,設計師也需要設計多套版式供前端使用,這給設計師、前端和測試帶來了無盡的麻煩。為此,我們通過前端技術重塑屏幕,重新定義像素尺寸,使用流式布局,通過百分比來響應不同的終端尺寸。這是端的融合。

后續的 Mobile 的技術發展方向上,應該是相當明確的。很多公司都是三套人馬維護三端的程序,iOS、Android 和 Web,而這三端做的事情都是一樣的,一樣的界面,一樣的后端接口,一樣的交互方式。為了能夠快速響應業務的變更,我們不得不將三端合并為一端對待,用一套程序編程成三端代碼,然后發布到三個平臺上。這也是端的融合。React 系列技術發展到此,絕對不是終點,它只是一個探路燈,給我們照明了方向。

技術需要為業務做保障,而好的技術是能夠及時響應業務的變化,我們不可能投入大量的人力在 Web 的修補工作上,通過開發統一工具,屏蔽端和端之間的差異,統一開發模式和開發體驗,這才是 Mobile 的未來。

當然,回到我們之前說的規范和標準,我們目前所做的「屏蔽差異」工作,今后,也會有統一的標準來規范,目前手機廠商沒有這個共識,是因為還處于當年 Chrome、Firefox 搶占 IE6 市場份額的階段。端的最終融合在于一個統一的標準,以及強有力的執行。

棧的融合

我剛接觸前端的時候,還沒有聽說「全棧」,Web 技術棧往小里說,包含了從前端設計、交互、前端實現、網絡數據傳輸、后端實現、后端運維和數據庫等幾個方面,能短時間內從無到有實現這么一套系統,并且能夠抗得住一定流量沖擊的人,我們可以稱之為全棧工程師。能夠有架構有條理地實現這套系統,并且抗得住大流量、有集成測試、有監控的,這種我們可以稱之為資深全棧工程師。現在不乏這種人才,也不乏自吹為這種人。

棧的融合得益于 Node.js 的出現,作為前后端分離的橋梁,它拉近了前端工程師與后端的距離,有的人在這座橋梁上賣力行走,漸漸的也從前端走進 了后端,甚至走進了后端的運維。至此,前端也擁有了部署和發布整個應用的能力,這是一個質的突破。

使用 Node.js,簡單幾行程序便能實現一個 web 服務器、便能搭建一個多人聊天的網頁,它的便捷性可見一斑。NPM 社區的發展,沉淀了成千上萬的組件包,一行命令即可獲取,這種組件拼湊式的開發,任何功能的實現都不會顯得太復雜,而這里的「不復雜」也蘊含了無數的坑坑洼洼,在這一層的融合上也會遇上不少阻礙:

  • 冗余的龐大的包內容,為了使用一個小功能,我們從網絡上拉取下來一個巨大的包,而且這里的「巨大」對很多人來說都是無感知的,很少會有人進入 node_modules 去查看依賴的第三方包是如何實現的,實際情況可能會相當震撼,第三方包還引用了一堆第三方包,這些包都會在 Node.js 執行的時候被收納進去,放在內存中。
  • 猛烈的迭代,今年的 Node.js 被人嫌棄迭代太慢了(當然,這是表面原因),走出了一個分支 io.js,發展了一會兒,進度趕超了 Node.js,后來覺得一家人不干兩家活,又合并回去了。雖說上層 API 幾乎沒有變化,但是底層卻被翻了一個天。
  • 偶爾的巨大漏洞,每隔一端時間就會暴露 Node.js 存在漏洞,這些漏洞的補救措施就是立即升級版本號,比較讓人擔心受怕。
  • 后端意識不強烈,前端占領了中間層的開發,有的時候還干這后端的活兒,然而卻沒有后端沉淀多年固有的意識,測試和監控做的相當潦草。

JavaScript 從客戶端的腳本語言縱身躍進進入了后端行列,而今也開始深入到移動端 Native 領域,確實是無孔不入,這可能就是語言的特性,也可能是技術本身就在尋求融合點,把有差異的地方全部躺平,然后用統一的方式去關注業務,關注用戶。端和棧也在融合。

后端服務化,云數據,云安全

用戶體驗變得越來越重要,響應式技術的發展也是后續網頁應用的一大特點,端和端之間的差異只是在表現上,數據這一層差異不是特別打,很多應用 PC 和 Mobile 共用一套接口,或者 Mobile 的接口在 PC 接口的基礎上做了一層包裝,對接口字段做了些許刪減。后端為了響應各個端之間的數據需求,也需要關注數據的可利用性,接口包裝的拓展性等,這是后端服務化的一個表現。移動端的開發上,前后端間隙十分明顯,越來越多移動端應用的發布已經脫離了后端,前端完全通過異步方式獲取數據。

業務變化很快很快快,今天這個產品被并購,明天那個業務被砍掉,每個人負責的業務線可能冷不丁地就變了。很多大公司的決策是由上往下的,上面微動,下面可能就是大動,可能某個部門就不存在了,也可能被劃分成幾個產品部門。

所以「大后臺,小前臺」的趨勢必然形成。前端,毫無疑問,在這個前臺之中。前臺的特點是靈活的,多變的,可快速重組的。對后臺而言,為了響應前臺的變化,需要提供更細粒化的 API,將數據打散,打得更加零碎,零碎的數據易于重組,這是在考驗后端的架構能力。如今,很多前端也都是半棧工程師,盤踞在前后端中間層上,然而如何迎接這種后端服務化的模式,似乎這個準備還是不夠充足的。

GraphQL 的出現場景跟 React 類似,React 是前端應對不同場景的一種強有力手段,而 GraphQL 則是后端應對不同需求場景的一次嘗試,Web APIs 將會成為 Web App 和 Mobile App 的一個中心點,前端基于后端的 RESTful 服務構建應用,這里面存在太多未知的問題需要探索,這是一個大數據下探索的新起點,也給前端開發者創造了無數的可能。

這幾年各類網盤,各個云服務商都在搶占市場,有提供圖片儲存的,有提供 CDN 靜態資源緩存的,有提供大文件儲存的,也有賣數據庫服務的。種類繁多,而歸根到底都是,你付錢給我,我提供儲存和安全,還提供方便的 SDK 讓你獲取自己的數據。云服務賣的是一套服務,它是把所有人的數據風險集于一身,用強硬的技術做安全防御。云,賦予了我們無窮的想象空間。

三輛馬車,我們還差一輛

開發功能對很多人來說是輕松活兒,基本的前端語言加些復雜的特效,實現成本不會很高;即便是搭建一個網站,使用 Node.js 社區中的框架也能夠輕松實現。然后極少人會去關注每個功能點的測試,一個項目下來基本看不到測試用例,更不用說會去做監控相關的事情。結果就是,踏過了無數的坑洼之后終于上線了,而后續加功能的時候發現,加了東西就跑不通,新內容影響了之前的邏輯,只好去修復之前的邏輯,修好之后發現更早之前的邏輯又不通了,整個修復過程就像玩多米諾骨牌。

程序開發三板斧:功能、測試和監控。在 github 上可以看到很多程序都加入了持續集成,這是一個好兆頭,以為著我們寫的程序也越來越健壯,至少貢獻給世人使用的程序是健壯的。很多程序的代碼覆蓋率也達到了 90%+,這些數據都是重視測試的證據。

然而,三輛馬車,我們最后一輛依然沒有開動起來。很多公司都會有自己的 log 平臺,每個用戶訪問頁面中的任何一個鏈接都會將用戶信息和訪問信息以 log 日志形式收集到 log 平臺上,然后通過監控平臺或者離線分析的方式,獲取業務數據或者技術數據,進行分析和二次開發。這些東西在大公司見的很多,而這方面的東西在前端,尤其是使用 Node.js 做程序開發的前端身上,看到的并不多。

最后

2016 年,我覺得技術上的新創造會稍微緩和些,這兩年很多人已經被新技術沖擊得有些找不著方向了,同一類東西,前者還沒學完,后者就開始火爆了,緊接著又是一陣技術的凋零和新技術的出現,這樣搞久了也會有一絲的疲倦。而更多的會關注,如何更好地服務多端,如何更大幅度地提升開發體驗和用戶體驗,很多技術都會往性能、往極致這個方向上鉆研。

寫長文真不輕松。寫到這里,感覺說的不通透,還有很多想說的,但是個人理解力有限,也難以表達全面。技術的變化很快,今天說過的東西,到了明天就可能過時了。我們猜不透未來,只能把現有的東西好好消化吸收下,留下一個話柄,給讀者吧。

參考資料

來自: http://www.barretlee.com/blog/2015/12/10/after-framework-we-gonna-to-hug-data/

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!