從最新的技術趨勢看前端的將來

本文僅表明 Phodal 的我的觀點，來聽聽一個前端程序員的 YY。

新一期的ThoughtWorks技術雷達有點出乎意料，使用new標籤的框架、工具、技術、語言等等超過了一半——Vue.js、ES2017上榜，Three.js憑着VR的火又上榜了，還有熟悉的Electron，以及微前端的概念。

讓咱們先看看一些技術亮點~~。

前端在可見的將來

在那篇《最流行的編程語言JavaScript能作什麼？》的文章裏，咱們看到了JavaScript在各個領域的應用。在這一期裏，仍然有不少亮點（new）：

Vue.js，若是你在使用Vue.js，那麼你更應該找到至關的自信了，如今它已經被列入了評估期了。Vue.js是一個簡單易上手的框架，而且至關的輕量，在最近的這段時間裏，它發揮得至關的出色。

惋惜，寶寶如今在用Angular.js 和 Angular 2，畢竟我如今是開發混合應用的。不過相信在半年後，Angular 2 和 Ionic 2是會上榜的。

Ember.js，儘管沒有證據代表這個框架在國內將火起來的趨勢，我如今還對這個框架缺少深刻的瞭解。

ECMAScript 2017，儘管我如今已經傾向於使用TypeScript，不過 ES2017 仍是會用到的，只是我以爲 Babel 對我來講就是個坑啊

Electron，若是你是一個老讀者，那麼你已經知道我在不少場合裏使用了這個框架，從NodeWebkit開始寫編輯器，再到用Electron完成Growth 1.0的桌面版。

Physical Web，如今咱們能夠在瀏覽器上來控制真實世界，經過藍牙低功耗技術。

不過與此相比，我更看好 Progressive Web App，畢竟他可讓Web應用接觸到更多的底層API，而不是侷限於藍牙，還能夠是Push Notification等等。

Three.js，它上榜的緣由是由於 WebVR 的流行。這一點能夠從我去年寫的那篇《Oculus + Node.js + Three.js 打造VR世界》，就能夠看到一些趨勢。這些就和如今的單頁面應用同樣，雖然運行起來不是那麼流暢，可是仍是行得通。於是在可見的將來使用 Web 技術來開發 VR 也有一點苗頭，將來瀏覽器上應該是能夠運行編譯事後的代碼，而不是在運行時。

WebRTC，它可讓咱們在瀏覽器端實現實時視頻聊天。第一次接觸到這個視頻流技術是在兩年多之前，上一次接觸則是在半年多之前使用 WebRTC + Oculus，你能夠在我博客的那篇《JavaScript在VR世界的應用》中瞭解到更多的詳細信息。固然如雷達所說，WebRTC將會造成將來在Web上進行AR/VR 協做的基礎。

接着再讓咱們看看一些架構上的變化吧。

前端引發的架構變化

在過去的兩三年裏，前端火得一塌糊塗——對於後端程序員來講，這有點 winter is coming 的感受。我在那篇《前端演進史》對前端的演進作了至關多的介紹，並在《後臺即服務演進史》裏對後臺即服務開了個頭，在這篇文章裏讓咱們根據《技術雷達》來繼續補幾刀。

咱們能夠看到在中大型團隊裏，已經分解爲前端和後臺兩個小組，溝通能夠經過接口、契約等等的方式來進行。可是這一點兒也不精益，溝通在這時仍然是一個問題，讓我有點懷念起以前先後端都作的項目了——本身能夠建立本身想要的接口。

不過，這意味着前端和後臺在技術選型上更加獨立了。

臃腫的前端——微前端

在上一個項目裏，咱們一步步地將一個有近10年系統的系統替換掉。起初這是一個傳統的Spring + JSP網站，而後咱們用JSP建立了JSON API，後來建立了一個新的 API 來服務移動應用和單頁面應用，再後來這個 API 被拆分紅了幾個 API。咱們的後臺已經成一個單體應用變成了一個微服務架構的應用，可是這一點並無在前端上應用——前端應用正在變得難以維護。

所以在這一期的雷達裏，你能夠看到微前端的概念（micro frontends）。這也是在上一個項目裏，咱們嘗試作的一部分，遺憾的是並無成功徹底實施。這是一個搜索類型的網站，網站的首頁承擔着大部分的訪問量，而詳情頁的主要流量來源則是搜索引擎。咱們在首頁上使用jQuery + Require.js技術棧，而在其餘頁面（搜索結果頁 + 詳情頁）使用 React.js，咱們在最初的時候考慮過將詳情頁靜態化——由於須要 SEO 的緣故，這樣可讓咱們下降 SEO 帶來的複雜度。

後來，我也在個人博客上解耦了兩部分，爲了更快的訪問首頁的速度——將首頁獨立出來，不使用JS，直接使用Pure.css來擔重任；在其餘頁面裏使用Material Design Lite做爲 UI 部分。

有一點值得考慮的是：對於微服務架構來講，在一個系統的不一樣的部分使用不一樣的技術棧是一種不錯的體驗；而對於一個前端團隊來講，在同一個系統的使用不一樣的技術棧就不是一種不錯的體驗。

API 設計——應該變得簡單

如咱們所見的Spring Boot已經變成推薦採用的程度了，按雷達上的習慣用語：「咱們已經在多個項目上使用這個框架」——反正我最近的項目都是用這個框架。若是你考慮使用 Java，那麼你必定不要錯過這個框架，以及使用這個框架來實施先後端分享。

對於大部分不須要考慮 SEO 的應用來講，將後臺變成一系列 RESTful 的 API 並非一件複雜的事，可是在後臺 API 上的設計就變成一件麻煩的事。所以儘管在實見的過程當中，有契約來做爲保證，可是不必定是可靠的。做爲一個前端程序來講，咱們在調用後臺 API 的過程當中，總會遇到這樣、那樣的問題。除此，還有接口很差用的問題——「要是你能夠在這裏使用超媒體 API，那麼個人代碼就會更加簡單了」。

所以在 API 設計上，雷達上給出了兩個不錯的案例：

強化後臺查詢

表明的例子就是 Facebook 的 GraphQL，它是在 Facebook 內部應用多年的一套數據查詢語言和 runtime。本來爲了請求一個用戶及其好友信息的請求，須要發起多個 API 請求。如今，咱們只須要在客戶端拼裝好對應的 Query語句，在這個語句裏將大部分須要查詢的東西寫好，即 JSON 格式的數據，而後發給服務端來處理。而在咱們客戶端上，咱們所獲取到的結果都是咱們所須要的，不須要再作特殊處理了。

這一切，看上去很美好——除了，在客戶端上拼查詢語句。

過去，咱們使用搜索引擎來搜索數據，就須要在前端拼好對應的 Query，再傳給後臺 API，由後臺 API 返回咱們須要的結果。在這個過程裏，咱們在Query作一些對應的數據處理。

反正，他們都是使用查詢語言來搜索結果。若是你考慮使用 QL 的話，不妨作一層 Wrapper，之後好作遷移。

先後端同時優化

Netflix對於這樣複雜的API請求下，建立了 本身的庫Falcor——它能夠從多個數據源獲取數據，並在服務端上彙總成一個 JSON model；在客戶端上，請求的時候咱們只須要在請求的時候加上對應的參數便可——能夠將多個請求合併到一塊兒，也能夠只針對某一個部分發出請求。這樣能夠減小發出多個請求，所帶來的複雜度。

我想，一種最實用的作法：就是將一些更新頻率較低的API合併成一個大的 API 了——大部分人都會這樣作吧。

簡化的後臺——無服務器架構

除了上面的這些內容，後臺還有一些東西還蠻好玩的，其中一個就是 Serverless 架構，即無服務器架構。不過，這種架構目前在國內運行起來仍是有點難度的，缺乏一系列的配套措施。如在這期的雷達上的Auth0能夠爲咱們提供一個受權服務，以及AWS Lambda能夠直接使用 AWS系列雲服務來對數據進行處理。

我就很少說了~~，讀者能夠本身去看。

那麼將來，你看想玩哪一種技術。

訪問 https://www.thoughtworks.com/... 獲取最新一期ThoughtWorks技術雷達（PS：若是你訪問不了原文連接，能夠修改DNS爲 8.8.8.8，或者放在個人GitHub Page上的備份：http://radar.phodal.com/2016.pdf ）