[[255443]]

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

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

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

技術規劃

W-H-Y

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

我們的目的是： 變得更好 。于是乎：“為什么我們就不能使用現在的架構？現在的架構不是挺好的嗎？？”

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

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

HOW

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

調研技術遠景

從社區獲得相應的輸入

整理潛在的技術方案、架構、技術棧

從利益相關者獲得想法。

制定相關的實施計劃

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

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

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

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

總之，保持現在，探索擴展，嘗試未來。

WHAT

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

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

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

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

前端 in 后端

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

Node.js 打造后端服務

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

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

Serverless

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

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

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

前端架構

由于前端的代碼量在不斷地增加，前端不在是一個大泥球架構，越來越多的新架構，將出現在前端領域。

微前端架構

微前端是一種類似于微服務的架構，它將微服務的理念應用于瀏覽器端，即將 Web 應用由單一的單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立運行、獨立開發、獨立部署。

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

如果你們的應用已經相當的大，記得采用微前端相應的技術。還有閱讀我寫的《微前端的那些事兒》。

組件庫及設計系統

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

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

BFF 架構

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

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

HTML 5 大型游戲

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

前端 in 前端

前端領域，在 2018 年已經趨于平衡，Angular、Vue、React 都沒有出現太大的變化。

框架

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

TypeScript

TypeScript 真香。

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

前端 in IoT

從 2018 年的趨勢來看，至少物聯網會在 2019 出現一定的上升趨勢。目前的主要表現階段，是在智能家居相關的領域。如果只是就一領域而言，那大抵還是不錯的。

筆者在撰寫《自己動手設計物聯網》時，使用的技術便是 JavaScript 作為后端和 Web 前端、移動應用的開發技術。而無疑的物聯網領域，除了現有的 Web 領域，還有各個地方都可以使用 JavaScript 作為開發語言。

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

開發工具完善

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

前端 in mobile

前端 in mobile，指的是用前端的技術來開發移動應用。

RN 及 Flutter

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

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

原生功能部分

原生 + H5 的頻繁更新部分

Fultter 的跨平臺部分

寫業務嘛，框架都只是工具。

小程序

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

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

安全

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

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

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

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