[[255443]]

新的一年里，有些新的技術(shù)會從實驗走向試用；有些技術(shù)，則會從試用走向采用；有些技術(shù)，則會從采用走向棄用。若是以此為出發(fā)點，那么這個 2019 年和過去的 2018 年相比，并不會有太大的區(qū)別。學一些新的技術(shù)，忘掉一些不同使用的技術(shù)。只是前端一個這么廣的領(lǐng)域，到底要關(guān)心什么技術(shù)，到底要忽略什么技術(shù)呢？

這便也是我寫下這篇文章的意義。可是呢，在寫作的過程中：“不行啊，我光告訴你 2019 將會流行什么，可能并沒有多大的意義。你們需要自己去學會擁有這樣的技能，學會去分析出 2020 需要規(guī)劃什么內(nèi)容。”

于此，本文便分為了兩部分，如何做前端規(guī)劃以及 2019 年我們需要什么。

技術(shù)規(guī)劃

W-H-Y

每每談到技術(shù)規(guī)劃，我們談的總是下一年、下一個階段、下一個五年的目標。可為什么我們需要做技術(shù)規(guī)劃？或許是出于 KPI 的影響，或者是出于預算的原因。

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

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

嗯，對這個問題就好像，別人在問你，“你有什么不足？”。

HOW

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

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

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

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

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

制定相關(guān)的實施計劃

規(guī)劃，它類似于技術(shù)遠景的味道。可一談到遠景，那么要談論的東西可多了。說不到我們還需要尋找利益相關(guān)者——如團隊成員、項目領(lǐng)導，了解一下，他/她對于技術(shù)團隊的一些期望。我們在社區(qū)上看到相似的問題，總有一個相似的開頭：“我們的領(lǐng)導……。”

談理想都特別有意思，因為我們不一定會去做。我們有了一個宏大的想法，只是受限于多個因素，我們只能做這么一點。比如說，我們未來想造一個筆記本，那么現(xiàn)在我們可以只選一個螺絲釘。

而在我們獲取更進一步方向的時候，需要從這么幾個維度來考慮問題：

從業(yè)務現(xiàn)狀出發(fā) 。譬如，在下一年里，我們的團隊將從 20 人擴大到 100 人，為了支撐這么大的團隊。我們需要擁有培訓機制，來應對這樣的人員擴張；需要設(shè)計一個更好的架構(gòu)，來實現(xiàn)多個團隊的并行開發(fā)。
從技術(shù)、架構(gòu)出發(fā) 。在項目中引入新的技術(shù)，改進原有的技術(shù)方案。
架構(gòu)的預研 。提前試用未來可能使用的技術(shù)，如 AR、VR。這些往往是一些非必需的規(guī)劃，但是有了它們會更好。
團隊能力規(guī)則 。談論到團隊規(guī)劃，我怕是并不是那么擅長。大抵上，哪怕是技術(shù)負責人也不是 KPI 的制定者，我們只能談談理想，聊聊團隊建設(shè)的一些建議。有針對性地培養(yǎng)項目的 2nd Tier，至少對方是否能接受，那便不在我們的控制之下。這大抵也是個人發(fā)展的好處，可以選擇自己感興趣的內(nèi)容學習。
當然了，其它相當多的東西，還是要落地的——我們還是得造螺絲釘。只有落地的東西，才能證明它是真正有價值的東西。為此我們要用 SMART 原則制定一個 smart 目標。當然了，如果你還要對領(lǐng)導匯報，請不到忘了你的時間節(jié)點。

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

WHAT

是不是我們規(guī)劃每件的事，都值得去做？是不是我們只做規(guī)劃的事情？未來是一直在發(fā)生變化的。而規(guī)劃，只針對我們知道的內(nèi)容提出的。它無法用于我們不知道的領(lǐng)域。它也無法應對未知的事務，如產(chǎn)生了一個新的技術(shù)，它提高了三倍的生產(chǎn)力。那么，先前我們設(shè)計的一些規(guī)劃，可能在此被新的技術(shù)替代掉了。

這方面的實踐，便有點類似于演進式架構(gòu)的味道。我們定好了一個大體的目標，核心的部分，只在真正實現(xiàn)的時候完善。為此，它需要具備一定的可演進式，也因此不會受過去的設(shè)計所限制。倘若基于這一點因素考慮，那便是容易得多了。只需要去尋找那些真正可能影響我們的趨勢，套上一個模糊的概念，就可以這么輕裝上陣。

可是呢，在做這件事情的時候， 每個人心里都有了一個答案 。事實上，你心底也已經(jīng)有了一個答案，只是說呢，你不敢、不想直接說出自己的想法——一來，受限于能力；二來，怕做了錯誤的決定。而直接、間接地，你在社區(qū)上看到一個大佬的回答，與你想要的答案是類似的。便將這個答案懷chen出來，信心也就有了，再說 “我們也可以這么搞”。好了，以后一旦出現(xiàn)了問題，還有一個人可以莫名地幫你背鍋。

大家活著都不容易，背鍋事小。責任，它與能力和屁股的位置是成正比的。

前端 in 后端

所謂的前端 in 后端，便是 在后端開發(fā)中，使用前端相關(guān)的語言和技術(shù)棧 。最典型的場景，便是使用 Node.js 開發(fā)后端服務。雖然 Node.js 已經(jīng)有了 10 年的歷史了，但是以我（Phodal）的角度來看，我更希望的是使用編譯型語言，來開發(fā)后端服務。動態(tài)語言，無法使用編譯器來檢測錯誤，難以約束代碼變動。

Node.js 打造后端服務

從社區(qū)的探索來看，存在一些完全使用 Node.js 開發(fā)的后臺服務。但是，也存在一系列由于代碼不規(guī)范造成的問題。從社區(qū)的經(jīng)驗來看，Node.js + Express + MongoDB + Angular/Vue/React，便是一些不錯的選擇。當然了，也有相當多的應用，只是采用了 Node.js 來完成 BFF 層（Backend For Frontends）。在這一層業(yè)務上，它只做業(yè)務數(shù)據(jù)的中間處理。

雖然，我經(jīng)常建議在一些關(guān)鍵的節(jié)點上，不要采用 Node.js 來打造后臺服務。可一旦涉及到 SPA 的服務端渲染，我們就不得不使用 Express、Koa 等這樣的服務端 JavaScript/TypeScript 框架，來解決這樣的問題。

Serverless

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

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

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

前端架構(gòu)

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

微前端架構(gòu)

微前端是一種類似于微服務的架構(gòu)，它將微服務的理念應用于瀏覽器端，即將 Web 應用由單一的單體應用轉(zhuǎn)變?yōu)槎鄠€小型前端應用聚合為一的應用。各個前端應用還可以獨立運行、獨立開發(fā)、獨立部署。

從筆者在 2018 年的實踐經(jīng)歷來看，微前端架構(gòu)確實是一個不錯的架構(gòu)方案。它能有效地解決臃腫前端應用、遺留前端應用和復雜前端應用。我們在項目上嘗試使用了多種不同的實踐方式：微件化、微應用化、路由分發(fā)、前端微服務化等。將一個應用分解，拆解成更多的應用，確實能相對高效地提升開發(fā)效率。

如果你們的應用已經(jīng)相當?shù)拇螅浀貌捎梦⑶岸讼鄳募夹g(shù)。還有閱讀我寫的《微前端的那些事兒》。

組件庫及設(shè)計系統(tǒng)

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

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

BFF 架構(gòu)

有越來越多的系統(tǒng)中，出于應對多端（Android、iOS、Web）變化的考慮，便在后端做數(shù)據(jù)相關(guān)的處理工作。為了更好的解耦業(yè)務邏輯，并提供更快的業(yè)務響應，便在這一層級采用了 BFF 架構(gòu)。BFF 全稱是 Backends For Frontends （服務于前端的后端），它是指在設(shè)計 API 時根據(jù)不同的設(shè)備類型，來返回不同的結(jié)果。

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

HTML 5 大型游戲

隨著移動端的性能不斷變好，在 2019 年，我開始看好使用 HTML 5 技術(shù)來開發(fā)一些游戲。當然了，主要原因還是微信小游戲的出現(xiàn)。但是，不管怎樣，我開始嘗試在這個領(lǐng)域的探索。

前端 in 前端

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

框架

架構(gòu)選型上，也趨勢于平衡。該用啥的還是用啥，偶爾還是會出現(xiàn)一些框架切換的新聞。盡管在 2019 年，會出現(xiàn)一些新的框架，但是還不太可能快引起變化。

TypeScript

TypeScript 真香。

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

前端 in IoT

從 2018 年的趨勢來看，至少物聯(lián)網(wǎng)會在 2019 出現(xiàn)一定的上升趨勢。目前的主要表現(xiàn)階段，是在智能家居相關(guān)的領(lǐng)域。如果只是就一領(lǐng)域而言，那大抵還是不錯的。

筆者在撰寫《自己動手設(shè)計物聯(lián)網(wǎng)》時，使用的技術(shù)便是 JavaScript 作為后端和 Web 前端、移動應用的開發(fā)技術(shù)。而無疑的物聯(lián)網(wǎng)領(lǐng)域，除了現(xiàn)有的 Web 領(lǐng)域，還有各個地方都可以使用 JavaScript 作為開發(fā)語言。

嵌入式 UI 界面。對于處理器資源豐富的設(shè)計來說，它們可以采用完整的瀏覽器來運行前端應用，而不再是裁剪過的引擎。
智能音箱。在過去一年里，已經(jīng)成為了一個新的入口了。而諸如 AWS Alexa 等都可以采用 Node.js 來開發(fā)語言技能。
嵌入式開發(fā)語言。諸如可以使用 JavaScript 作為開發(fā)語言的 IoT.js。事實上，它會變成類似于 Emacs 架構(gòu)，由原生來實現(xiàn)編譯器，由動態(tài)語言來增長特性。
……
你覺得呢？

開發(fā)工具完善

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

前端 in mobile

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

RN 及 Flutter

依我的角度來看，使用什么跨平臺框架來看，區(qū)別并不是太大。目前主流的方案，仍然是原生（含跨平臺框架） + HTML5 應用。從業(yè)務的角度上來看待這個問題，那么還是希望，可以用 HTML 5 的地方多——更新功能方便。

也因此，雖然在過去，筆者寫過基于 React Native 的混合應用框架 Dore。我相信：Flutter 也會出現(xiàn)這樣的混合應用框架。不過，對于有原生開發(fā)能力的團隊來說，它們的框架還會是三部分：

原生功能部分

原生 + H5 的頻繁更新部分

Fultter 的跨平臺部分

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

小程序

小程序，即 HTML5 小程序，即無需安裝即可下載運行的應用程序。與普通的移動 Web 應用不同的是， 小程序相當于是高階版的混合應用 。

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

安全

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

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

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

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