最近小伙伴們應(yīng)該陸續(xù)回公司開始擼代碼了，在新的一年里，有些新的技術(shù)會(huì)從實(shí)驗(yàn)走向試用；

有些技術(shù)，則會(huì)從試用走向采用；

有些技術(shù)，則會(huì)從采用走向棄用。若是以此為出發(fā)點(diǎn)，那么這個(gè) 2019 年和過去的 2018 年相比，并不會(huì)有太大的區(qū)別。

學(xué)一些新的技術(shù)，忘掉一些不同使用的技術(shù)。

只是前端一個(gè)這么廣的領(lǐng)域，到底要關(guān)心什么技術(shù)，到底要忽略什么技術(shù)呢？

前端是個(gè)最近幾年火起來的工種，而且持續(xù)火熱中，有個(gè)詞叫水漲船高，來的人多了，競爭多了，標(biāo)準(zhǔn)也就提高了。

現(xiàn)在對(duì)前端工程師的要求跟當(dāng)年前已經(jīng)不能同日而語了。

今天給大家分享下前端的趨勢，當(dāng)然了，所謂的趨勢，不是一天兩天就到來的，它是未來的一個(gè)技術(shù)方向。

我們之所以關(guān)注趨勢，是要關(guān)注變化，技術(shù)的發(fā)展與普及不是一日之功，一定是慢慢過渡的，但是你能夠比其他人提前看到方向。

真正的市場到來的時(shí)候，你就可以提前做好準(zhǔn)備，提前發(fā)掘機(jī)會(huì)。

我光告訴你 2019 將會(huì)流行什么，可能并沒有多大的意義。你們需要自己去學(xué)會(huì)擁有這樣的技能，學(xué)會(huì)去分析出 2020 需要規(guī)劃什么內(nèi)容。

W-H-Y

每每談到技術(shù)規(guī)劃，我們談的總是下一年、下一個(gè)階段、下一個(gè)五年的目標(biāo)?？蔀槭裁次覀冃枰黾夹g(shù)規(guī)劃？或許是出于 KPI 的影響，或者是出于預(yù)算的原因，或是在追求技術(shù)卓越。

我們的目的是： 變得更好 。于是乎：“為什么我們就不能使用現(xiàn)在的架構(gòu)？現(xiàn)在的架構(gòu)不是挺好的嗎？？”

為此，我們只需要嘗試回答這么幾個(gè)問題：項(xiàng)目的編譯速度快嗎？編寫新功能的速度快嗎？能滿足快速上線的需求嗎？多個(gè)團(tuán)隊(duì)并行開發(fā)，會(huì)出現(xiàn)問題嗎？我們依賴的第三方組件，會(huì)出現(xiàn)問題嗎？……

嗯，對(duì)這個(gè)問題就好像，別人在問你，“你有什么不足？”。

HOW

從這篇文章的寫作過程，及筆者的相應(yīng)規(guī)劃步驟來看，可以分為這么幾步：

調(diào)研技術(shù)遠(yuǎn)景

從社區(qū)獲得相應(yīng)的輸入

整理潛在的技術(shù)方案、架構(gòu)、技術(shù)棧

從利益相關(guān)者獲得想法。

制定相關(guān)的實(shí)施計(jì)劃

規(guī)劃，它類似于技術(shù)遠(yuǎn)景的味道。可一談到遠(yuǎn)景，那么要談?wù)摰臇|西可多了。說不到我們還需要尋找利益相關(guān)者——如團(tuán)隊(duì)成員、項(xiàng)目領(lǐng)導(dǎo)，了解一下，他/她對(duì)于技術(shù)團(tuán)隊(duì)的一些期望。我們?cè)谏鐓^(qū)上看到相似的問題，總有一個(gè)相似的開頭：“我們的領(lǐng)導(dǎo)……?！?/span>

談理想都特別有意思，因?yàn)槲覀儾灰欢〞?huì)去做。我們有了一個(gè)宏大的想法，只是受限于多個(gè)因素，我們只能做這么一點(diǎn)。比如說，我們未來想造一個(gè)筆記本，那么現(xiàn)在我們可以只選一個(gè)螺絲釘。

而在我們獲取更進(jìn)一步方向的時(shí)候，需要從這么幾個(gè)維度來考慮問題：

從業(yè)務(wù)現(xiàn)狀出發(fā) 。

譬如，在下一年里，我們的團(tuán)隊(duì)將從 20 人擴(kuò)大到 100 人，為了支撐這么大的團(tuán)隊(duì)。

我們需要擁有培訓(xùn)機(jī)制，來應(yīng)對(duì)這樣的人員擴(kuò)張；需要設(shè)計(jì)一個(gè)更好的架構(gòu)，來實(shí)現(xiàn)多個(gè)團(tuán)隊(duì)的并行開發(fā)。從技術(shù)、架構(gòu)出發(fā) 。

在項(xiàng)目中引入新的技術(shù)，改進(jìn)原有的技術(shù)方案。

架構(gòu)的預(yù)研 。提前試用未來可能使用的技術(shù)，如 AR、VR。這些往往是一些非必需的規(guī)劃，但是有了它們會(huì)更好。

團(tuán)隊(duì)能力規(guī)則 。談?wù)摰綀F(tuán)隊(duì)規(guī)劃，我怕是并不是那么擅長。

大抵上，哪怕是技術(shù)負(fù)責(zé)人也不是 KPI 的制定者，我們只能談?wù)劺硐?，聊聊團(tuán)隊(duì)建設(shè)的一些建議。

有針對(duì)性地培養(yǎng)項(xiàng)目的 2nd Tier，至少對(duì)方是否能接受，那便不在我們的控制之下。這大抵也是個(gè)人發(fā)展的好處，可以選擇自己感興趣的內(nèi)容學(xué)習(xí)。

當(dāng)然了，其它相當(dāng)多的東西，還是要落地的——我們還是得造螺絲釘。只有落地的東西，才能證明它是真正有價(jià)值的東西。

為此我們要用 SMART 原則制定一個(gè) smart 目標(biāo)。當(dāng)然了，如果你還要對(duì)領(lǐng)導(dǎo)匯報(bào)，請(qǐng)不到忘了你的時(shí)間節(jié)點(diǎn)。

總之，保持現(xiàn)在，探索擴(kuò)展，嘗試未來。

WHAT

是不是我們規(guī)劃每件的事，都值得去做？是不是我們只做規(guī)劃的事情？未來是一直在發(fā)生變化的。

而規(guī)劃，只針對(duì)我們知道的內(nèi)容提出的。它無法用于我們不知道的領(lǐng)域。它也無法應(yīng)對(duì)未知的事務(wù)，如產(chǎn)生了一個(gè)新的技術(shù)，它提高了三倍的生產(chǎn)力。

那么，先前我們?cè)O(shè)計(jì)的一些規(guī)劃，可能在此被新的技術(shù)替代掉了。

這方面的實(shí)踐，便有點(diǎn)類似于演進(jìn)式架構(gòu)的味道。

我們定好了一個(gè)大體的目標(biāo)，核心的部分，只在真正實(shí)現(xiàn)的時(shí)候完善。

為此，它需要具備一定的可演進(jìn)式，也因此不會(huì)受過去的設(shè)計(jì)所限制。倘若基于這一點(diǎn)因素考慮，那便是容易得多了。

只需要去尋找那些真正可能影響我們的趨勢，套上一個(gè)模糊的概念，就可以這么輕裝上陣。

可是呢，在做這件事情的時(shí)候， 每個(gè)人心里都有了一個(gè)答案 。

事實(shí)上，你心底也已經(jīng)有了一個(gè)答案，只是說呢，你不敢、不想直接說出自己的想法——一來，受限于能力；

二來，怕做了錯(cuò)誤的決定。而直接、間接地，你在社區(qū)上看到一個(gè)大佬的回答，與你想要的答案是類似的。

便將這個(gè)答案懷chen出來，信心也就有了，再說 “我們也可以這么搞”。好了，以后一旦出現(xiàn)了問題，還有一個(gè)人可以莫名地幫你背鍋。

大家活著都不容易，背鍋事小，不帶人身攻擊就好。責(zé)任，它與能力和屁股的位置是成正比的。

我們從基礎(chǔ)來看，在對(duì)2019前端開發(fā)如何進(jìn)階，提升自己，再做更深一層講解。

1 基礎(chǔ)技術(shù)

前端的三大基礎(chǔ)毫無疑問就是HTML、CSS和JS。我稱之為前端的骨、肉和魂。

先說“骨”——HTML。HTML,翻譯過來就是超文本標(biāo)記語言，而不是江湖上的HOW TO ML。方向不能搞錯(cuò)了，我們整的東西可是老少咸宜的。HTML學(xué)習(xí)最重要的標(biāo)簽的學(xué)習(xí)，div、h1-h6、p、ul-li、strong、圖片、字體等，什么內(nèi)容用什么框.

再說“肉”——CSS。CSS定義了HTML標(biāo)簽的顯示外觀，氣質(zhì)。主要掌握浮動(dòng)，寬高設(shè)置、顯示屬性等

最后“魂”——Javascript。這是運(yùn)行在瀏覽器上的腳本，但是現(xiàn)在javascript已經(jīng)遠(yuǎn)遠(yuǎn)不是當(dāng)年的那個(gè)js了，尤其Ecmascript6標(biāo)準(zhǔn)出來后，nodeJS 橫空出世，JS暴露出一統(tǒng)天下的野心，JS讓網(wǎng)頁變得靈活，其實(shí)現(xiàn)的每一個(gè)明里暗里的交互，其實(shí)是為了觸及您的靈魂，這也是其成為魂的原因。

而現(xiàn)在，CSS3和HTML5的發(fā)展，又將web推向下一個(gè)時(shí)代，一個(gè)更為豐富多彩的時(shí)代。

2 環(huán)境基礎(chǔ)

設(shè)備、瀏覽器以及工作原理

必須指出的是，html CSS JS都是運(yùn)行在瀏覽器的，是由瀏覽器負(fù)責(zé)編譯和呈現(xiàn)的。所以必須了解瀏覽器的工作原理。但是瀏覽器千千萬萬，也不是每個(gè)都要去解剖，主要的有Chrome, Firefox, IE，Safari,Opera,國內(nèi)的主瀏瀏覽器基本是基于chrome內(nèi)核開發(fā)，做了一些更為接地氣的功能，了解下就可以了，主要有QQ瀏覽器，UC，百度瀏覽器，360瀏覽器，搜狗瀏覽器，獵豹瀏覽器等。

3 計(jì)算機(jī)基礎(chǔ)

計(jì)算機(jī)網(wǎng)絡(luò)，http協(xié)議。既然是web必不可少需要知道計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)，這對(duì)于網(wǎng)頁的加載和速度優(yōu)化有很大的幫助，并且，我們做的不是靜態(tài)的頁面，而是動(dòng)態(tài)的，所以必然涉及到與后臺(tái)之間的數(shù)據(jù)的傳輸和存儲(chǔ)，這個(gè)是要掌握的。

必須懂：Ajax，必須會(huì)的工具：fiddler

4 流行框架

流行的前端UI框架：

Bootstrap、jQuery UI、Amaze UI

流行的前端框架：

Node.Js

jquery mobile

angular.Js

Vue.js

React.js

5 可視化組件

Echarts

tableau(收費(fèi))

所謂的前端 in 后端，便是 在后端開發(fā)中，使用前端相關(guān)的語言和技術(shù)棧 。

最典型的場景，便是使用 Node.js 開發(fā)后端服務(wù)。

雖然 Node.js 已經(jīng)有了 10 年的歷史了，但是以我的角度來看，我更希望的是使用編譯型語言，來開發(fā)后端服務(wù)。

動(dòng)態(tài)語言，無法使用編譯器來檢測錯(cuò)誤，難以約束代碼變動(dòng)。

作為一個(gè)新興的技術(shù)領(lǐng)域范圍，大前端在不同的語義環(huán)境下，有著不同的解釋和含義，我們以幾個(gè)視角去對(duì)大前端并做逐一的分析。

Node.js 與前后端分離

在絕大多數(shù)的前端開發(fā)者口中，大前端有時(shí)與 Node.js 一起講，有時(shí)與前后端分離一同講，事實(shí)上，大前端概念也正是由廣大前端開發(fā)者提出的。

過去幾年，前端技術(shù)經(jīng)歷了爆發(fā)式的發(fā)展，這種發(fā)展最重要的推動(dòng)者之一就是 Node.js。

Node.js 為前端建立了與系統(tǒng)之間溝通的橋梁，從此前端技術(shù)不僅能在服務(wù)端大放異彩，并且在本地的前端開發(fā)工具與工作流上大展身手，前端從此被解放，JavaScript 統(tǒng)治世界的論調(diào)一度甚囂塵上。

不過，當(dāng)人們冷靜之后，發(fā)現(xiàn) Node.js 在服務(wù)端并沒有太多的優(yōu)勢，再加上 Node.js 本身技術(shù)發(fā)展的一些波折，導(dǎo)致它在服務(wù)端的應(yīng)用并不理想。

但盡管如此，廣大的前端開發(fā)者還是取得了一些階段性勝利，其結(jié)果就是前后端分離。

在傳統(tǒng) Web 開發(fā)時(shí)代，前端頁面模板是由后端生成的，導(dǎo)致在頁面需要頻繁修改的時(shí)候，效率極低。

前后端分離指的是后端只提供接口，前端對(duì)頁面有完整控制，同時(shí)通過中間層將前后端隔開，在這里對(duì)數(shù)據(jù)進(jìn)行抽取、聚合、分發(fā)等操作。這個(gè)中間層，通常也是由前端開發(fā)工程師負(fù)責(zé)。

從這種意義上講，大前端的原始定義可以稱為前端技術(shù)的擴(kuò)大化，包括 Node.js，同時(shí)對(duì) Web 頁面有更強(qiáng)的控制權(quán)，開發(fā)也將承載更多功能的頁面。

從社區(qū)的探索來看，存在一些完全使用 Node.js 開發(fā)的后臺(tái)服務(wù)。

但是，也存在一系列由于代碼不規(guī)范造成的問題。

從社區(qū)的經(jīng)驗(yàn)來看，Node.js + Express + MongoDB + Angular/Vue/React，便是一些不錯(cuò)的選擇。

當(dāng)然了，也有相當(dāng)多的應(yīng)用，只是采用了 Node.js 來完成 BFF 層（Backend For Frontends）。在這一層業(yè)務(wù)上，它只做業(yè)務(wù)數(shù)據(jù)的中間處理。

雖然，我經(jīng)常建議在一些關(guān)鍵的節(jié)點(diǎn)上，不要采用 Node.js 來打造后臺(tái)服務(wù)。

可一旦涉及到 SPA 的服務(wù)端渲染，我們就不得不使用 Express、Koa 等這樣的服務(wù)端 JavaScript/TypeScript 框架，來解決這樣的問題。

作為一種折中方案，也是我最喜歡的方案。

Serverless 架構(gòu)是指大量依賴第三方服務(wù)（也叫做后端即服務(wù)，即“BaaS”）或暫存容器中運(yùn)行的自定義代碼（函數(shù)即服務(wù)，即“FaaS”）的應(yīng)用程序，函數(shù)是無服務(wù)器架構(gòu)中抽象語言運(yùn)行時(shí)的最小單位。

采用 Serverless 架構(gòu)，也就意味著，我們提取出了大量的基礎(chǔ)設(shè)施。而使用 Node.js + JavaScript 作為膠水，來快速連接不同的服務(wù)，以形成一個(gè)快速有效的方案。并且，編寫更少的代碼，也意味著更安全、快速。

除了直接基于 AWS 的 Serverless Framework 框架的方案，還有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。

由于前端的代碼量在不斷地增加，前端不在是一個(gè)大泥球架構(gòu)，越來越多的新架構(gòu)，將出現(xiàn)在前端領(lǐng)域。

微前端是一種類似于微服務(wù)的架構(gòu)，它將微服務(wù)的理念應(yīng)用于瀏覽器端，即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用。

各個(gè)前端應(yīng)用還可以獨(dú)立運(yùn)行、獨(dú)立開發(fā)、獨(dú)立部署。

從筆者在 2018 年的實(shí)踐經(jīng)歷來看，微前端架構(gòu)確實(shí)是一個(gè)不錯(cuò)的架構(gòu)方案。

它能有效地解決臃腫前端應(yīng)用、遺留前端應(yīng)用和復(fù)雜前端應(yīng)用。

我們?cè)陧?xiàng)目上嘗試使用了多種不同的實(shí)踐方式：微件化、微應(yīng)用化、路由分發(fā)、前端微服務(wù)化等。

將一個(gè)應(yīng)用分解，拆解成更多的應(yīng)用，確實(shí)能相對(duì)高效地提升開發(fā)效率。

如果你們的應(yīng)用已經(jīng)相當(dāng)?shù)拇?，記得采用微前端相?yīng)的技術(shù)。還有閱讀我寫的《微前端的那些事兒》。

自 Ant Design 的圣誕節(jié)事件之后，我相信： 在 2019 年，有越來越多的團(tuán)隊(duì)將構(gòu)建自己的組件庫 。一種頗為簡單的方案，便是：

評(píng)審一個(gè)開源組件庫 Ant Design、Material Design 等
在開源組件庫的基礎(chǔ)上，進(jìn)行二次封裝。如 <AutoComplete /> 變成 <pho-AutoComplete>
替換部分的開源組件代碼
隨后，在那些的基礎(chǔ)上，加入自己的模式庫和設(shè)計(jì)系統(tǒng)。

有越來越多的系統(tǒng)中，出于應(yīng)對(duì)多端（Android、iOS、Web）變化的考慮，便在后端做數(shù)據(jù)相關(guān)的處理工作。

為了更好的解耦業(yè)務(wù)邏輯，并提供更快的業(yè)務(wù)響應(yīng)，便在這一層級(jí)采用了 BFF 架構(gòu)。

BFF 全稱是 Backends For Frontends （服務(wù)于前端的后端），它是指在設(shè)計(jì) API 時(shí)根據(jù)不同的設(shè)備類型，來返回不同的結(jié)果。

除了，采用 Node.js 中相應(yīng)的后端框架，作為 BFF 層的開發(fā)模式。GraphQL 是在 2018 年特別流行的一種 BFF 模式，毫無疑問在 2019 年也是一個(gè)值得考慮的方案。

隨著移動(dòng)端的性能不斷變好，在 2019 年，我開始看好使用 HTML 5 技術(shù)來開發(fā)一些游戲。

當(dāng)然了，主要原因還是微信小游戲的出現(xiàn)。但是，不管怎樣，我開始嘗試在這個(gè)領(lǐng)域的探索。

前端領(lǐng)域，在 2018 年已經(jīng)趨于平衡，Angular、Vue、React 都沒有出現(xiàn)太大的變化。

架構(gòu)選型上，也趨勢于平衡。該用啥的還是用啥，偶爾還是會(huì)出現(xiàn)一些框架切換的新聞。

盡管在 2019 年，會(huì)出現(xiàn)一些新的框架，但是還不太可能快引起變化。

TypeScript 真香。

前端，沒什么好看——除了，娛樂新聞。

從 2018 年的趨勢來看，至少物聯(lián)網(wǎng)會(huì)在 2019 出現(xiàn)一定的上升趨勢。

目前的主要表現(xiàn)階段，是在智能家居相關(guān)的領(lǐng)域。如果只是就一領(lǐng)域而言，那大抵還是不錯(cuò)的。

筆者在撰寫《自己動(dòng)手設(shè)計(jì)物聯(lián)網(wǎng)》時(shí)，使用的技術(shù)便是 JavaScript 作為后端和 Web 前端、移動(dòng)應(yīng)用的開發(fā)技術(shù)。

而無疑的物聯(lián)網(wǎng)領(lǐng)域，除了現(xiàn)有的 Web 領(lǐng)域，還有各個(gè)地方都可以使用 JavaScript 作為開發(fā)語言。

嵌入式 UI 界面。對(duì)于處理器資源豐富的設(shè)計(jì)來說，它們可以采用完整的瀏覽器來運(yùn)行前端應(yīng)用，而不再是裁剪過的引擎。

智能音箱。在過去一年里，已經(jīng)成為了一個(gè)新的入口了。而諸如 AWS Alexa 等都可以采用 Node.js 來開發(fā)語言技能。

嵌入式開發(fā)語言。諸如可以使用 JavaScript 作為開發(fā)語言的 IoT.js。事實(shí)上，它會(huì)變成類似于 Emacs 架構(gòu)，由原生來實(shí)現(xiàn)編譯器，由動(dòng)態(tài)語言來增長特性。
……
你覺得呢？

開發(fā)工具的完善，一直在每年的規(guī)劃里。在 2019 年里，也是如此，引入更好的工具，如更好的拖拽工具，更好的代碼生成工具——由 AI 生成。

前端 in mobile，指的是用前端的技術(shù)來開發(fā)移動(dòng)應(yīng)用。

依我的角度來看，使用什么跨平臺(tái)框架來看，區(qū)別并不是太大。

目前主流的方案，仍然是原生（含跨平臺(tái)框架） + HTML5 應(yīng)用。從業(yè)務(wù)的角度上來看待這個(gè)問題，那么還是希望，可以用 HTML 5 的地方多——更新功能方便。

也因此，雖然在過去，筆者寫過基于 React Native 的混合應(yīng)用框架 Dore。我相信：Flutter 也會(huì)出現(xiàn)這樣的混合應(yīng)用框架。

不過，對(duì)于有原生開發(fā)能力的團(tuán)隊(duì)來說，它們的框架還會(huì)是三部分：

原生 + H5 的頻繁更新部分

寫業(yè)務(wù)嘛，框架都只是工具。

小程序，即 HTML5 小程序，即無需安裝即可下載運(yùn)行的應(yīng)用程序。與普通的移動(dòng) Web 應(yīng)用不同的是， 小程序相當(dāng)于是高階版的混合應(yīng)用 。

如果只是從這一點(diǎn)上來看，其實(shí)是不是和微信一樣的定制型小程序，并不是那么重要。重要的，在于與原生 界面結(jié)合，并提供離線使用功能。 它也是小程序與普通的 HTML 應(yīng)用的區(qū)別。

從 2018 年的前端社區(qū)經(jīng)驗(yàn)來看，NPM 包的安全，也成為了一個(gè)值得考慮的問題。

也因此 2019 年，也不得不進(jìn)行相應(yīng)的安全機(jī)制的設(shè)計(jì)。

也因此 2020年，也不得不進(jìn)行相應(yīng)的安全機(jī)制的設(shè)計(jì)。

也因此 2021 年，也不得不進(jìn)行相應(yīng)的安全機(jī)制的設(shè)計(jì)。

http://news.51cto.com/art/201901/590502.htm