【CSDN 編者按】又是新的一年。承上啟下的總結會讓人變得清朗，一方面是對過去的總結，另一方面是嚮往未來。這篇文章總結了前端技術在過去一年的發展，深入淺出，值得一看！
作者 | 三鑽 責編 | 張文
頭圖 | CSDN 下載自視覺中國
出品 | CSDN（ID：CSDNnews）
2020 年已經結束，因為疫情，大家的生活和工作或多或少都受到一定影響。儘管如此，但前端技術的發展並沒有停止腳步。
作為前端開發者，需要對技術的更新換代有所瞭解。雖然不需要去學習所有新出來的技術，但是時刻保持 “瞭解” 和 “理解” 是有必要的。本文盤點了 2020 年前端的一些新老技術發展和趨勢。
重點會放在這幾個方面：
“瞭解” 這個東西是做什麼的
“理解” 這個東西是為了解決什麼問題的
“知道” 這個東西可以怎麼使用（使用場景）
微前端 （Miro frontends）
"微前端" 應該是 2020 年裡聽的最多的一個前端技術。不少大廠在嘗試利用這個新技術來解決大型前端項目中的問題。
雖然我們前端開發中有模塊化（modular）組件（components），但它相比後端的 “微服務” 是大有不同的。
在瞭解 “微前端” 之前，我們先給沒有接觸過後端的同學補一下後端的 “微服務” 知識。
微前端的起源和後端一樣，就是一個模塊因為業務和功能的持續發展，導致模塊內容的代碼越來越複雜，越來越龐大，同時就會造成與其他業務有不可避免的互相影響的關係。
就是這些模塊與模塊之間的關係，讓我們的系統變得越來越難以維護，大大減低了開發的 “敏捷性”。
那麼怎麼辦呢？我們就讓一個大型的 app 業務按模塊拆分成一個一個小的 “服務” 模塊。這些小的模塊會與後端的接口一樣，放在單獨的服務器上運行，同時也會有單獨的小團隊進行專門的開發和維護。
這種微型的獨立前端架構體系和系統就叫做 “微前端”。
“微前端” 應用開發團隊擁有整個應用生命週期自主性。這就包塊獨立開發、獨立版本號管理、獨立測試、獨立打包、獨立渲染、獨立更新、獨立部署。
在上圖中，我們可以看到微前端在一個研發中心裡的組織架構。每個微前端團隊都會負責一個獨立的業務模塊，每個模塊都會有他們自己的核心業務。與其他業務的功能其實是相對獨立的，但是業務的流程上他們就會通過數據流、交互流、接口等方面串聯起來。
最終用戶所體驗到的系統，其實跟我們普通的應用沒有什麼區別。但是從大型應用開發和維護的角度來看，好處甚多。
微前端的好處
自主性 —— 可以對每一個微前端應用進行獨立的開發、部署、維護和擴展，而不影響其他微前端應用的功能。
專用性 —— 每個微前端應用都是針對一組功能而設計的，並專注於解決特定的問題。如果開發者逐漸講更多的代碼增加到一項微前端應用當中，從而讓這個微前端應用變得複雜時，那麼我們可以將其再次拆分成多項小的微前端應用。
敏捷性 —— 微前端是由若幹個小型獨立團隊形成的一個組織，這些團隊負責自己的微前端應用。個團隊在小型而易於理解的環境中進行開發，並且可以更獨立，更快速地工作。這個縮短了開發週期的時間。
靈活擴展 —— 通過微前端化應用，我們可以獨立擴展組件和功能來滿足其他應用的需求。這使團隊能夠適當調整基礎設施需求，準確的衡量功能成本，並在服務需求激增時保持可用性。
輕鬆部署 —— 微前端支持持續集成和持續交付，可以輕鬆和放心的嘗試新的想法，並可以在無法正常運行時獨立回滾某一個應用。由於微前端應用直接都是獨立的，所以問題只會發生在自己的應用當中，所以我們可以大膽的試驗，更輕鬆地更新代碼，並縮短新功能的上線時間。
技術自由 —— 微前端架構不遵循 “一刀切” 的方法。團隊可以自由選擇最佳的工具或者框架來解決他們的具體問題。也就是說一個微前端應用可能是用 Vue，然後另外一個可能是用 React 也不是不可以的。因此，構建微服務的團隊可以為每項作業選擇最佳的工具或者框架。
可重複使用 —— 將前端應用劃分成明確定義的模塊，讓團隊可以將功能用於多種目的。轉為某項功能編寫的前端模塊可以用作另一項功能的構建塊。這樣應用程序就可以自行引導，因為開發者可以創建新的功能，而無需衝頭開始編寫代碼。
彈性 —— 前端應用獨立增加了應用程序應對故障的彈性。在整體式架構中，如果一個組件出現故障，可能導致整個應用程序無法運行。通過微前端的拆分架構，應用程序可以通過降低功能而不導致整個應用程序崩潰來處理總體服務故障。
微前端案例
這裡幻想一下，我們有一個博客主頁。主要功能就是為了展示文章內容。當然一個博客其實很簡單，在正常開發場景下，也不會給它做微前端的架構設計。
但是如果我們真的想把它做的更強大，那也是可以的：
當然這個還不是很複雜，但是當我們繼續往這個博客平臺加入更多的功能，比如最後做成 CSDN 這樣的平臺的時候，那麼微前端就有必要了！
微前端集成方法
好，如果真的有那麼一天，我們變成一個很大的博客平臺。那麼我們要怎麼運用微前端呢？其實集成方法有很多種：
服務器端模板組合 （Server-side template composition）
構建時集成 （Build-time integration）
通過 iframes 在運行時集成 （Run-time integration via iframes）
通過 JavaScript 在運行時集成 （Run-time integration via JavaScript）
通過 Web 組件在運行時集成 （Run-time integration via Web Components）
其實所有的集成方法，都圍繞著一個很自然的設計模式 —— 一個應用裡面的每個頁面都是一個 “單獨的” 微前端應用。而在每個頁面中都會有一個“單獨的應用容器（single container application），而它的作用就是：
渲染頁面公共頭部（headers）和腳步（footers）
解決 “橫切關注點（Cross-cutting concern）”，比如身份驗證和導航
把多個微前端應用放在一個頁面之中，並且告訴每個微前端應用在什麼時候和在哪裡渲染到頁面上。
大概的頁面設計如下：
注意這裡只講到微前端的皮毛，其實微前端最核心並不在前端，更多的難點都是在 “雲服務器”。如果沒有服務器架構、部署、測試等等的支撐，微前端是很難以實現的。所以在一般公司的應用場景，其實根本用不上微前端。
原子設計 （Atomic Design）
原子設計也是在 2020 年裡提到的非常多的一個概念。不過這個更多隻是一個概念，並不是一個純方法論。
這個概念是 Brad Frost 提出的，他用化學中的原子組成來分析和拆解一個 Web 應用的組成成分。裡面包含原子（Atoms）、分子（Molecules）、生物（Organisms）等。
比如一個搜索分子（Search Molecule）就是由 input-text（輸入文本）+ button（按鈕）+ label（標題）等原子所組成。然後這些分子組合起來就會變成一個生物（Organism）。
而生物（Organism）就會生存在我們頁面的佈局模版之中，而這些就可以具體化成一個頁面，最後顯示給到我們的用戶。
Brad Frost 把前端的組件和界面設計抽象成化學中的原子組成結構。讓我們更加清晰的去理解一個頁面、一個組件、一個元素的組成方式。
其實這個概念可以讓我們用一個全新的角度去看待模塊化 UI（modular UI）。這種思維方式讓我們更深入的理解一個組件的作用和 API，從而在設計組件的時候會更加的清晰和高效。
一個簡單易懂的表示圖：
原子（Atom）是什麼？
原子是物質的基本組成部分。而在組件設計中，原子就是一個組件的最小元素單位，一個組件都是用多個原子所組成的。
在 Web 界面中，原子就可以是：HTML 標籤
表格的 label
輸入框 input
按鈕 button
原子單獨使用是沒有任何意義的，一般都是需要組合其他原子一起使用才能真正發揮它們的作用。
分子（Molecule）是什麼？
當我們把原子（Atoms）結合在一起時，事情開始變得更加的有趣。分子（Molecule）是一組結合在一起的原子，是化合物中最小的基本單位。每一個分子都有自己的特性，是我們設計系統的支柱（Backbone）。
比如，一個表格標題、輸入框、按鈕等元素，它們單獨使用時沒有太大用處的。但是如果我們把它們組合在一起，變成一個表格。這個時候它們就可以使用了。
在我們用原子組合分子時，我們需要遵循一個原則：“只做一件事，並且做好”。（這個聽起來是不是有點像設計模式裡面的：“單一職責”？是的，就是這個意思。）雖然分子可能很複雜，但根據經驗，他們相對而然都是一些簡單的原子而組成的，主要是為了可複用性而生。
生物（Organism）是什麼？
分子可以作為我們組建界面的積木。我們可以把分子組合在一起來建立一個生物體（也就是我們的一個界面）。生物是用一組分子組合而成的，而組成的生物體是界面的其中一部分，它有相對複雜，獨特的特性。
就比如上圖，我們在組合了一個網頁 logo 部分的分子。然後我們把搜索分子和 logo 分子再組合在一起，就變成了界面上頭部（生物體）的部分（header organism）。
這個就會開始變得越來越有趣了，生物不是一個固定的組件，它是用多個分子所組合而成。不同的生物體可能存在使用相同的分子或者原子，但是他們的作用都是有所不同的。
就比如，我們的 logo 和文章圖片兩個不同的分子，他們相同都使用了 img 圖片標籤這個原子。但是這個 img 原子是放在了兩個不同職責的分子裡面，一個是用在頭部作為 logo 展示的，一個是用在文章列表用來展示圖片的。
所以在組建分子和用分子組件生物體的時候，我們創建的組件必須是獨立的、可移植、可重用的。
模版（Templates）
有了分子組成的生物體（Organism）後， 我們就可以用這些生物體來組件我們的界面模版。這裡我們就可以打破化學的類比，擁有對用戶和最終輸出更有意義的東西。
模版主要是由多個生物體縫合在一起而形成的頁面。在這裡，我們開始看到組件和模塊的設計開始融合在一起，可以看到佈局之類的東西開始有所體現了。
模版是非常具體化的，它為所有的這些相對抽象的分子和生物體提供了上下文。模版階段也是用戶可以開始看到設計界面的地方。根據這個設計的創作者 Brad Frost 的使用經驗，模版一開始是 HTML 線框，但隨著時間的推移，它的保真度會逐漸提高，最終成為可交付的產品。
頁面（Pages）
頁面（pages）是模版的特定實例。這裡，佔位符內容被真實的，有代表性的內容所取代，以準確地表現方式描述了用戶最終將要看到的內容。
頁面是最真實的，因為它們是最有形態的，它通常是大多數人在開發過程中花最多時間來處理和優化的部分。
頁面這個階段非常的重要，因為這裡是我們測試設計系統有效性的地方。在上下本中查看一切，是我們能夠回頭來修改我們的分子（Molecules）、生物體（Organism）和模版（Templates）。
頁面也是測試模版變化的地方。例如，我們可能想清楚地表達包含40個字符的標題最終展示到給用戶是什麼樣子的，但是也想演示340個字符是什麼樣子。當用戶的購物車中有一件商品與應用了折扣的時候，商品的展示會是怎麼樣的。這些實際的情況會影響我們如何循環和構建我們的應用。
為什麼用原子設計理念？
我們簡單理解了原子設計後，我們就可以問問，為什麼要用原子設計呢？
其實答案很簡單，我們平時去設計一個應用的時候，即使我們沒有意識去使用這種思維方式，但是我們一直都是以這種方式在設計的。
原子設計為設計系統提供了一種清晰的方式輪（概念為主），團隊成員（開發者、產品經理、設計師等）能夠通過實際看到的，擺在他們面前的步驟來更好地理解設計系統的概念。
原子設計賦予我們從抽象到具體的能力。正因如此，我們可以創建促進一致性和可伸縮性的系統，同時在最終的歡迎中顯示內容。
重點是通過組合而不是解耦的方式來構建應用。我們在一開始就創造了一個系統，而不是在事後才去挑選模式。
封裝樣式和 Shadow DOM
組件開發最重要的一個方面是封裝（Encapsulation）—— 就是能把標記（markup）和行為隱藏起來，並與頁面上的其他代碼分開，這樣不同的部分就不會衝突，代碼也可以保持整潔。
而要做到這樣，Shadow DOM API就是關鍵。它可以將一個隱藏的、獨立的 DOM 附加到一個元素上。
Shadow DOM 允許將隱藏的 DOM 樹附加到常規的 DOM 樹中 —— 它以 shadow root 節點為起始根節點，在這個根節點的下方，可以是任意元素，和普通的 DOM 元素一樣。
一些 Shadow DOM 特有的術語：
Shadow host：一個常規 DOM節點，Shadow DOM 會被附加到這個節點上。
Shadow tree：Shadow DOM內部的DOM樹。
Shadow boundary：Shadow DOM結束的地方，也是常規 DOM開始的地方。
Shadow root: Shadow tree的根節點。
我們可以使用與常規 DOM 一樣的方式來操作 Shadow DOM —— 例如，添加一個子節點、設置屬性、以及為節點添加自己的樣式，或者為整個 Shadow DOM 添加樣式。
與不同 DOM 不一樣的是，Shadow DOM 內部的元素始終不會影響它外部的元素（除了 :focus-within），這為封裝提供了便利。
其實 Shadow DOM 並不是一個全新的東西，它已經被瀏覽器使用了很長一段時間了。瀏覽器用它來封裝一個寫元素的內部結構，以一個有著默認播放控制按鈕 元素為例。
我們所能看到的只是一個 標籤，實際上，在它的 Shadow DOM 中，包含了一系列的按鈕和其他控制器。Shadow DOM 標準允許我們自己的元素（custom element）維護一組 Shadow DOM。
這種方式也常常被認同為是組件樣式封裝的最佳解決方案。
基本用法
首先我們可以使用 Element.attachShadow() 方法來將一個 shadow root 附加到任何一個元素上。
這個方法接受一個配置對象作為參數，這個對象有一個 mode 屬性，它的值可以是 open 或者 closed：
open：表示可以通過頁面內的 JavaScript 方法來獲取 Shadow DOM, 例如使用 Element.shadowRoot 屬性：
但是如果我們把 Shadow root 附加到一個自定義元素（Custom element）上，並且把 mode 設置為 closed，那麼我們就不可以從外部獲取到 Shadow DOM 了 —— myCustomElem.shadowRoot 將會返回 null。
其實瀏覽器中的 就是這樣的，裡面就包換了一個不可訪問的 Shadow DOM。
如果你想將一個 Shadow DOM 附加到 custom element 上，可以在 custom element 的構造函數中添加如下實現（目前，這是 shadow DOM 最實用的用法）：
將 Shadow DOM 附加到一個元素之後，就可以使用 DOM APIs對它進行操作，就和處理常規 DOM 一樣。
詳細的使用方式，可以直接去看 MDN 的 《使用 shadow DOM》。
TypeScript 的崛起
有報告統計，80% 的開發者承認想在下一個項目中使用或者學習 TypeScript。
雖然 TypeScript 還有它的缺點，但它讓代碼更容易理解（對於習慣編寫面向對象的同學，確實好理解，但是不熟悉面向對象的同學，就有點難受了）。並且 TypeScript 可以更利於快速實現。
那麼我們應不應該轉 TypeScript 呢？在決定之前，我們還是冷靜一下，看看使用 TypeScript 的優缺點，然後根據我們自己團隊的技術情況再做選擇才是合理的。
使用 TS 的好處
1. 代碼更容易理解
很多時候當我們在看一段代碼中的一個函數，我們都會問以下問題：
這個參數是可以接受那些的？
函數會返回什麼值？
它需要什麼外部數據？
它做了什麼可以把輸入參數變成輸出的返回值？
在動態類型語言中，通常很難回答前三個問題。
但是在像 TypeScript 這樣的靜態類型語言中，我們可以立即從 IDE 和編譯器中得到上述的所有問題的答案。不再需要查看整個代碼庫，不斷地向我們的同事提出問題，或者在生產上出錯誤的風險。
2. 更容易，更快的實現代碼
當我想要實現一個新的功能或者組件，我們的工作流大概是這樣子的：
初始化組件函數，建立它的構造函數參數，編寫剩下的代碼。
如果它需要任何外部或複雜的數據（如用戶或文章），那麼就要將它保存在我們自己的內存中，並在代碼中使用它。
將組件放入你的應用中，並將 props 傳遞給它。
然後就是測試這個組件，手動或者使用單元測試（這裡我們需要確保它能接收到該有的 props，並且它能正常工作。）
如果有什麼地方出現了 bug，那麼就要回到我們的代碼，試著找到哪裡出了問題。再回到第 1 步。
上述是在使用 JavaScript 的開發流，那麼如果我們用的是 TypeScript 的話就會變得更簡單，更高效了：
初始化組件函數，定義它的類型，並且實現它。
如果它需要任何外部或複雜的數據，直接查找它們的接口並重用它們（全部或部分）。
將組件放入你的應用中，並將 props 傳遞給它。
就是這樣！（如果在調用者和被調用者之間正確地匹配了類型定義，那麼一切都應該能夠完美地工作。現在唯一需要測試的是組件的實際業務邏輯。）
是不是簡單很多了？這個也是為什麼 TypeScript 出現的低級錯誤會更少的原因。
3. 代碼容易重構
在開發中，我們肯定是會有很多代碼在編寫後，都需要我們去重構的。但是因為往往都涉及太多的東西和文件，所以我們開發者一聽到一個項目需要重構代碼基本都是這樣：
在 TypeScript 中，這類重構的事情變得不那麼可怕。往往一個重構只需要輕輕在 IDE 的按一下 “重命名符號（Rename Symbol）” 命令即可。
在動態類型語言中，同時重構多個文件時，我們能得到的最好的幫助就是使用RegExp 進行搜索和替換。
而在靜態類型語言中，不再需要搜索和替換了。使用IDE命令，如“查找所有出現的情況”和“重命名符號”，可以看到應用程序中特定的函數、類或對象接口屬性的所有出現情況。
如果我們想稍微改進我們的構建系統、重命名組件、還是修改對象或者刪除廢棄的屬性，我們都不必擔心破壞任何東西。TypeScript 會幫助我們找到重構後的這些相關聯的東西的用法，重新命名它，並如果在我們重構後出現了類型不匹配的情況，它就會發出編譯錯誤的警告。
4. 更少的 bugs
做了多年的前端開發，我們都知道如果有一個人在我們旁邊，在我們拼寫錯變量名、使用了一個不一定會是 null 的值、或者傳了一個對象類型參數給一個接收數組類型的函數的時候提醒一下我們，那麼我們就可以省下 50% 的排錯時間。
很高興的告訴大家，這個好基友就是 TypeScript。
多謝它，現在想編寫一個 bug 也變得相對難了。當我們的代碼打包的時候，我們可以大概知道我們的代碼是可以運行的通的。
5. 更少的樣板測試
當我們確定我們傳的參數是對的，那麼我們就不用去測試所有地方調用了某個方法是否會報錯，對方有沒有用對參數，用對類型，用對我們提供的方法。
少了這些的顧慮，我們就可以更多的集中在編寫業務邏輯的單元測試，而不是代碼的語法和準確性的保障測試。
既然我們減少了檢測代碼中報錯的問題，我們就可以花更短的時間來完成新功能和需求。這樣我們的代碼就不會很複雜，更不容易出錯，更容易維護。
6. 幫助開發者寫更好的代碼
當我們在編寫靜態類型語言時，首先我們需要想，我們需要的數據類型是怎麼樣的，然後想我們想產出的數據又是怎麼樣的。這個過程就需要在我們坐下來開始寫代碼之前就要想清楚。
其實還有很多同學在開始實現一個功能和需求之前，缺乏了思考和分析。沒有認真的思考過整個代碼和邏輯的思路、實現的方法、數據的類型、函數的結構等。但是對於老司機程序員來說，很多都是先思考然後才去動鍵盤的。
那麼 TypeScript 就會要求我們遵循這種好的開發思維。它鼓勵我們在坐下來實現功能和代碼之前，先要考慮清楚我們要實現的功能的接口類。
TypeScript 的缺點
說了那麼多 TypeScript 的優點，我們也來講講它的缺點。
1. 需要編譯步驟
如果我們是開發Node.js 後端的開發者，如果使用 TypeScript 確實會變得比較麻煩。因為我們需要先編譯了 .ts 的文件，然後才能在 Node 上去運行。
當然如果我們有一個好的打包工具鏈，這個問題還是可以解決的。但是確實會 Node.js 後端的同學帶來本來沒有的麻煩。
不過相對前端開發者來說，這個並不是任何問題。因為現代的前端開發流程，我們都會把所有的前端代碼通過 webpack、grunt 等打包工具我編譯我們的代碼。
那麼 .ts 文件在這個過程已經自動的幫我們編譯過來了。所以我們不需要做任何附加的步驟。頂多也是多在打包工具中使用 npm 多安裝一個編譯插件。
2. 設置起來有點困難
不可置疑，這一點確實是事實。比如，在普通 Next.js 和使用 TypeScript 的 Next.js 之間，使用了 TypeScript 我們就要附加 Node.js 服務器、webpack 和 jest test 測試工具。
還有，當我們需要添加一個像 React、Redux、Styled-Components 等 library 的時候，我們都要為他們附加 typedefs。（比如 @types/styled-components，不過有一些包本身就自帶有 TS typedefs 文件）
不過我覺得這些問題並不大，因為在長期開發和維護一個項目的過程中，安裝依賴包和設置一個 TypeScript 項目，相對比我們平時編寫算法和業務邏輯的評率，其實是非常微小的一部分。基本上這些繁瑣的事情都是一次過搞好就行，如果還是覺得繁瑣，做一個 toolchain 工具，每次需要操作這些重複的事情的時候，直接用工具幫我們構建即可。
那要不要用 TypeScript 呢？
TypeScript 固然是好，畢竟 Vue 3 的重構中也在很多語言中最後選擇了 TypeScript 作為他們的核心語言。
所以 TypeScript 的好處是顯而易見的。但是任何的技術選型都要看我們自己所在的團隊和公司。如果有 10 個開發，9 個都不會 TypeScript，並且都不太願意去學，或者公司根本給不到時間讓我們團隊去學習新的語言。
那麼選擇換這個語言就不是最佳的選擇。
沒有最好的技術，只有最合適當下使用的技術。
Web 組件就是前端的未來?
Web 組件就是前端的未來，為什麼呢？
因為純 Web 組件與任何的前端框架無關，他們可以在沒有框架或者使用任何框架的情況下工作。
因為這些組件更加不受 “JS 疲勞（JavaScript Fatigue）” 所控制，並且大部分瀏覽器都是支持的。
因為它們的包大小和消耗是更有優勢的，加上 VDOM 渲染擁有令人震驚的能力。
這些組件提供了自定義元素、一個 Javascript API （允許我們定義一種新的 html 標記）、html 模板來指定佈局，當然還有 Shadow DOM（本質上是特定於組件的）。
這裡解釋一下什麼是 JS 疲勞 —— 就是當我們想學習前端的時候，第一個接觸的語言必然就是 JavaScript，但是一旦開展學習後，就會發現這個水是真的深，一大竄的其他關聯知識就會如同潮水一樣撲面而來。包括，前端框架、Node.js、UI 框架、瀏覽器知識、工具鏈等等。學習前端一開始確實是一個非常疲勞的一個領域。
當我們思考未來 UI 開發，以及模塊化、可重用性、封裝性和標準化的原則時，組件（化）時代應該是怎麼樣子時，Web 組件就會浮現在未來的藍圖上。
狀態管理：再見 Redux？
無論是 React 的 Redux 還是 Vue 的 Vuex 其實都是特別難搞的大魔頭。儘管隨著前端變得越來越模塊化，在應用程序中的全局狀態管理變得越來越難以控制。但是狀態管理（State Management） 像 Redux 和 Vuex 的實用性和實用性使他們成為許多團隊的首選解決方案。
所以我們在 2020 年之後可以和 Redux 說再見了嗎？不，不完全可以。
然而，在前端框架中的狀態管理體系不斷的涌現（如 React hook、Context-API 等），未來很有可能會廢除掉對框架以外的狀態管理的依賴。
像 Mobx，一開始這些類型技術還很少被採用，但是由於它們面向組件和可延伸性的特性，僅僅在 2020 年這一年內，它們開始變得越來越流行，讓我們開發這可以在探索更多的選擇。
MobX 是一個經過戰火洗禮的庫，它通過透明的函數響應式編程(transparently applying functional reactive programming - TFRP)使得狀態管理變得簡單和可擴展。MobX 背後的哲學很簡單:
任何源自應用狀態的東西都應該自動地獲得。
其中包括 UI、數據序列化、服務器通訊，等等。
ESM CDN
ES 模塊就是在瀏覽器使用模塊時的標準，而 ES 模塊就是被 ECMAScript 所標準化的。使用 ES 模塊，你可以很容易地將功能封裝到模塊中，這些模塊可以通過 CDN 來使用。
隨著 Firefox 60 的發佈，所有主流瀏覽器都將支持 ES 模塊，Node mteam 正在努力向 Node.js 中添加 ES 模塊的支持。此外，WebAssembly 的 ES 模塊集成也將在未來幾年內推出。
漸進式網絡應用（PWA）
漸進式網絡應用也叫 Progressive Web Apps —— 它利用最新的技術將網頁和移動應用程序的有點結合起來。可以把 PWA 想成一個使用 Web 技術的網站，但是行為和感覺是一個應用程序（APP）。最近在瀏覽器、服務的可用性 worker、Push APIs 的發展與進步，允許用戶在主界面安裝 Web 應用程序，甚至接收推送通知和離線工作。
由於 PWA 是提供了親密的用戶體驗，而且所有的網絡請求都可以通過 service worker 被攔截。因此，必須將應用託管在 HTTPS 上，從而防止 “中間人” 攻擊，這也意味著更好的安全性。
當然，PWAs 仍然有侷限性，它們不能完全替代本地應用。（不過，它們真的需要那麼做嗎？）特別是，由於本質上是網頁，PWAs 不能使用大多數硬件功能，如 NFC 和藍牙。然而，並不是所有的應用程序都需要這些功能。
不過 PWAs 開發起來更快、更容易、更便宜，這就是為什麼它們在 2020 年成為開發的趨勢，並且在下一年肯定會繼續成為趨勢的原因。
WebAssembly (WASM)
JavaScript 很棒，但是也不是沒有缺點。JavaScript 是存在有性能的問題的。所有解析醒語言都面臨同樣的問題，而 WebAssembly 是解決這個問題的最新途徑。
WebAssembly 最好的一個點是，它並不是一門全新的語言。我們可以用自己喜歡的語言來編寫，然後將其編譯成 WASM 文件，以便在瀏覽器中運行。WebAsssembly 目前支持的語言有 C/c++、Elixir、Python、Go、c#/.Net 和 Java。
WebAssembly 不是最近才有的，它已經上市好幾年了。但它發展的迅速，提供了越來越多的選擇。默認情況下，現在所有主流瀏覽器都支持它，如果程序員 能擁有它是一件非常有益的事情。
可訪問性（a11y）
可訪問性，也叫 Accessibility —— 這是 Web 應用層序開發中最重要的東西之一。我們相信可訪問性，應該是每一個網站開發者的任務列表的收腰任務，不經是新網站，而舊網站的更新也是一樣。
可訪問性（或 a11y）是一個計算機系統對用戶的 “方便性” 的考量原則。網站應該能在各種設備上正常運行。但它們應該適用於各種“障礙”和“殘疾”的用戶。A11y 通常指軟件和硬件的可訪問性。
在網頁開發方面，可以透過以下途徑達成易讀性：
更大或可自定義的字體大小
可選的高對比度的頁面
支持語音合成/文本到語音的轉換
視頻字母
所有語音都附有文本
導航語音識別
純語言文字
突出重要部分
一致的導航和儘可能少的步驟
簡化授權（但不犧牲安全性）
用鍵盤導航，而不是鼠標/觸控板
語義 HTML
a11y 這個名字來自於 “accessibility” 中有 13 個字母，所以在 “a” 和 "y" 之間有 11 個字母。但如果你仔細看，a11y 看起來像 “ally” 這個詞 —— 意思是朋友、助手、拍檔的意思。
JavaScript 框架 （Frameworks）
最後我們來講以下 2020 年中一些我們可以關注以下的前端框架。
Gatsby.js
Gatsby 是一個 SSG，全稱是 Static Site Generator（靜態站點生成器）。如果我們認為靜態站點已經成為過去，反而它們輸入全新的技術趨勢。
GatsbyJs 最大的優點之一是它不需要傳統的服務器；它與 BYOC（Bring Your Own Content —— 自帶內容）一起工作，可以基於 CMS、CSV、API 和 markdown 文件中的數據構建網站。Gatsby 還使用一種高端 API 查詢語言 GraphQL 來構建數據層。
掌握 GatsbyJs 要求開發者瞭解 React Native 和/或 GraphQL，但我們不需要馬上就有深入的知識 —— 我們可以同時學習 Gatsby + React Native + GraphQL，也就是邊學著做 Gatsby 邊學習 React 和 GraphQL。
因為 GatsbyJs 是一個 SSG，所以它非常適合開發電子商務網站。這個基於 React 的生成器，可以幫助我們在一瞬間就能加載完網站。我們這裡說的不是秒，而是毫秒級的加載速度。任何電子商務企業所有者都知道，有時頁面加載時的延遲，會對客戶是否購買產品產生很大的影響。這個也適用於其他類型的網站。
Vue 3 - One piece
在 2019 年的 6 月底，Evan You（尤雨溪）和 vuejs 背後的團隊發佈了一個關於 Vue 3 框架的新迭代的 RFC（徵求意見 —— Request For Comment），在社區中遇到了相當多的否定。但是最後這個事實證明，這些負面的反饋並沒有那麼影響 Vue 3。
一些 Web 開發者陷入困境，因為 Vue.js 突然有了一個基於函數的組件 API（Component API）來取代大部分人已經熟悉的對象 API。然而，這並不完全正確，新的基於函數的組件 API 是對排序的補充，如果我們願意，我們是可以與傳統的對象 API 一起使用的。
Vue 3 組合 API 中的新語法具有更好的邏輯性，有助於更好的代碼結構。一些開發者甚至說它稍微縮短了代碼。而且 Vue 3 架構可以作為 Vue 2 的插件使用，只需要使用 Vue Composition（組合式） 庫即可。
然後在 2020 年 9 月 18 日，Vue 3 的正式版發佈了，命名為 One Piece（這個名字很多同學一看就知道來源於海賊王）。
Vue 3 帶來的新特性
1. 性能
雙向相應原理由 Object.defineProptry 改為基於ES6 的 Proxy，這樣使顆粒度更大，速度更快，從而消除了之前存在的警告；
重寫了 Vdom，突破了 Vdom 的性能瓶頸；
進行了模塊編譯的優化；
進行了更高效的組件初始化邏輯；
2. Tree-Shaking 支持
支持了 tree-shaking（剪枝）：像修剪樹葉一樣把不需要的東西給剪切掉，這樣 Vue 3 的體積就變得更小了。
因為有了 tree-shaking，vue 3 中的模塊只有需要的時候才會被打入到包裡、優化後的 Vue 3 的打包出來的體積將會是原來的一半（僅 13kb）。就算我們把所有的功能都引入了，打包出來也只有 23kb，依然還是比 Vue 2.x 更小。
有了這個，像 keep-alive、transition、甚至 v-for 都是可以按需引入了。
3. Composition API
其實 Composition API 的靈感來自於 React Hooks， 它是比 mixin 更強大的存在。它可以提高代碼邏輯的複用性，從而實現與模版的獨立性；同時函數式的編程代碼的可壓縮性更強。
另外，Reactivity 在 Vue 3 中獨立開來，意味著 Vue 3 的響應式模塊可以與任何其他的框架相組合使用。
4. Fragments
不再限制 template 只有一個根結點。並且 render 函數也支持返回數組，有點想 React 中的 React.Fragments。
5. 更好的 TypeScript 支持
Vue 3 擁有更好的類型推導，使得 TypeScript 的支持變得非常好。
6. 自定義 Renderer API
實現了用 DOM 的方式進行 WebGL 編程。
Svelte.js
Rich Harris 在 2019 年的 JSConf EU 上發佈，Svelte（中文意思是 “苗條”）與 Vue相似又不同。類似的是，它也是一個組件架構。然而，與 Vue 不同的是，Svelte 的組件編譯器是在構建時（Build Time）運行的。這使得我們可以只加載需要展示目前 APP 的組件。我們不需要使用任何的虛擬 DOM（Virtual DOM）。
Svelte 使用一套簡單的語法，使開發者能夠從標記訪問變量，而不是使用每個框架都不一樣的狀態包裝器（state wrapper）。這就使得 Svelte 成為 Web 開發新手的一個近乎完美的框架（就是非常好上手）。而對於有豐富經驗的開發者來說，Svelte 意味著可以更快地編寫代碼，從而獲得更高性能的網站。
在它發佈之後的一年裡，Svelte 經歷了許多的重大改進和更新，最終形成了許多開發人員現在所說的，最簡單和最漂亮的框架之一。
CSS 框架
框架就是為了使一切變得更簡單，其中包括被眾多歷史遺留困擾的 CSS。讓我們看看 2020 年裡 CSS 中流行的技術。
Houdini CSS
在最新的 Web 發展趨勢中，Houdini（取名於著名的魔術師 Harry Houdini）是一個非常獨特的框架。基本上，Houdini 是一個 API 集合，為開發者提供了對 CSS 對象模型的訪問。這個意味著，如果你需要 CSS 中還沒有的樣式，沒有必要用 JavaScript 去修改或者覆蓋。我們直接使用 Houdini CSS 架構，就可以編寫被瀏覽器視為 CSS 並被解析的代碼去操作樣式。
使用這種方式可以使解析花費的時間更少，開發者不需要等待瀏覽器提供商擴展的 CSS，設計可以變得更加易於定製和更獨特。
不過還有一個問題：並不是所有的主流瀏覽器都支持 Houdini。但是現在我們只能等待這個框架被所有主流瀏覽器支持。
Bulma
Bulma 是現代的行業趨勢之一。他是用 Sass 擴展構建的，基於 CSS 靈活的框佈局模塊，或也稱為 Flex 佈局。Flexbox 是一個經常用於構建響應式網站的模塊。
Bulma 是一個免費的開源 CSS 框架，它提供了一系列由社區創建的主題，這些主題都遵循這一個原則，就是儘可能的少寫樣式。由於使用了 Sass 構建，它實現起來非常簡單，而且可以自定義。由於 Bulma CSS 代碼的簡單性，用它構建的網站通常與所有瀏覽器兼容，幾乎沒有問題。目前，它是開發者中最流行的 CSS 框架之一，而且看起來在 2021 年裡面還是會保持這一個地位。
Tailwind
Tailwind CSS 框架已經存在一段時間了，但是在 2020 年才得到更高的關注度。
如果我們看谷歌的熱度趨勢圖，我們可以看 Tailwind CSS 的熱度還在持續的往上升。
Tailwind 的特別之處在於它不是一個 UI 工具包，這使它與其他 CSS 框架不同。它沒有內置的 UI 組件，相反，Tailwind 提供了一組部件（英文叫 widgets）來快速的開發出 UI 組件或者界面，而這些部件是使用一系列的 class 工具叫 Atomic CSS 。這意味著我們可以按照自己的需求從頭開始構建或者自定義開發 UI 組件，而不被其他 CSS 框架提供的主題和樣式所限制。
不過，我們需要熟悉這套 Atomic CSS 工具，這就使得對開發者來說使用 Tailwind 會更有一點挑戰性和學習曲線。好的一面就是，它會給你最自由的 UI 開發體驗。
總結
在 2020 年裡面，前端領域依然在高速發展中。新的技術在不停的涌出，已有的技術和框架也在不斷的更新迭代。隨著技術的發展，前端這個領域在 2021 年裡面依然會技術以光速發展。
很多在前端領域的同學在很多群裡都會說 “不要再跟新啦，不要再出新的框架啦，學不動了～”
所以我們真的所有的新技術都要學嗎？並不是的，重點是我們不要為了技術而技術，而是為了解決問題而學一門新技術。我覺得這個很值得我們深思的。
重點不是框架那個以後發展更好，而是瞭解每個框架為什麼存在，當下有什麼問題導致有了這些框架，以後可能會有什麼問題，可能需要什麼東西來解決。
說到這裡很多同學就會問，那麼我們應該往哪個方面發展呢？
我覺得月影老師說的可以參考：“基礎和底層知識，基礎和底層知識，基礎和底層知識。”
因為所有框架也好，新技術也好。我們也不確定以後會出來什麼，最後哪個會一統天下，或者那個會默默的隱退江湖。
所以重點是我們需要學習，保持可以快速上手任何框架和技術的能力。其實無論是 Vue，React，Angular 還是 Flutter。底層不都是 JavaScript 嗎？甚至 Node.js 也是。然後更底層呢？不就是計算機基礎知識嗎？如果我們這些學通透了，那麼以後出來什麼各種花樣，難道我們不能在一週內學會嗎？（可能不能一週內，但是快速上手還是可以的嘛）
基礎知識還有像數學，這些都是永世不會變的知識。而往往這些知識都是我們開發者的基礎。而這些基礎才是我們真正能適應這個技術高速發展的時代。也是這些基礎讓我們不會害怕任何的變化。因為我們擁有可以適應任何變化的能力。
我們需要關注前端每年的發展、熱點、和趨勢。但是不需要盲目的跟風，甚至去學習新的東西。更多是觀望這些科技的發展，瞭解它們，當我們需要用到它們的時候再去深度學習它們，解決我們當下在項目中遇到的問題。這個才是正確的方向和心態。
作者簡介：在一線工作五年的程序員，起步於 PHP，最後轉型專研前端。Vue、React 使用者，專於 Web 和移動端開發。擔任過技術合夥人、研發主管、技術總監等職位。也做過前端和後端的開發和架構設計。有豐富的商城、ERP、CRM 系統研發經驗。並且有搭建和管理過 20 人的技術團隊。
本人非常熱愛開源，在 GitHub 上有開源的項目、工具、組件等。從 2020 年頭開始寫博客至今，一年內在多個博客平臺上獲得了 “優秀作者獎”、“原力突破 Top 15”、“原力王者 Top 10”、“學習力周榜榜單”、“CSDN 博客專家” 等榮譽。
程序員如何避免陷入“內卷”、選擇什麼技術最有前景，中國開發者現狀與技術趨勢究竟是什麼樣？快來參與「2020 中國開發者大調查」，更有豐富獎品送不停！
轉載請超鏈接註明：頭條資訊 » 前端沒有末日
免責聲明
：非本網註明原創的信息，皆為程序自動獲取互聯網，目的在於傳遞更多信息，並不代表本網贊同其觀點和對其真實性負責；如此頁面有侵犯到您的權益，請給站長發送郵件，並提供相關證明(版權證明、身份證正反面、侵權鏈接)，站長將在收到郵件24小時內刪除。