2020 年已經結束，這一年里面因為疫情，生活和作業中大家都有受到一定的影響，但是在 2020 年里面前端技術的發展依然沒有停止腳步，
而我們作為前端開發者，必定需要對技術的更新換代有所了解，雖然我們不需要去學習所有新出來的技術，但是時刻保持 “了解” 和 “理解” 這些技術是有必要的，
了解這些新的技術和趨勢，有效讓我們成為更好的開發者，同時在我們日常作業中，這些知識有效幫助我們去解決作業中的技術問題，或者在一個問題中看到更多的解決辦法和可能性，
這篇文章盤點了 2020 年里面，關于前端的一些新技術、它們的發展和趨勢，
但是我們并不需要所有都去深入了解，我們的重點應該放在這幾個方面：
- “了解” 這個東西是做什么的
- “理解” 這個東西是為了解決什么問題的
- “知道” 這個東西可以怎么使用（使用場景）
「1」微前端 （Miro frontends）
“微前端” 應該是我們 2020 年里聽的最多的一個前端技術，現在非常多的大廠都在嘗試這個新技術來解決大型前端專案中的問題，
雖然我們前端開發中有模塊化（modular）的組件（components），但是它相比后端的 “微服務” 是大有不同的，
在了解 “微前端” 之前，我們先給沒有接觸過后端的同學科補一下后端的 “微服務” 知識，
微服務是什么？
微服務是一種開發軟體的架構和組織方法，其中軟體由通過明確定義的 API 進行通信的小型獨立服務組成，這些服務由各個小型獨立團隊負責，
上面的專業術語不好理解的話，我們也可以這么理解，微服務 —— 也就是把單獨一個業務寫成一個獨立的服務，有獨立的服務器、介面體系、并且有一個單獨的團隊進行開發與維護，
就比如，淘寶的訂單和用戶兩個 “模塊”，一開始這些模塊我們可能都會設計在一起的，這樣開發起來需要的開發資源和時間就相對比較小，畢竟微服務不是一個 5 - 6 人團隊可以 hold 得住的，
等業務變得非常龐大的時候，隨著功能和資料的不斷在擴大和延伸，這個時候訂單和用戶模塊都變得非常的復雜，這個時候就需要我們把這兩個模塊單獨的拆離出來開發和維護，因為，如果我們不拆離出來，每次改這些模塊的一個小功能，都會涉及很多影響，我們就會發現這個系統越來越難迭代，改一個功能或者 bug 都會開始變得非常的困難，
這個就是為什么后端提出了微服務這個概念，為了解決大型應用的維護難題，把業務解耦、隔離、獨立化就是解決方案，
既然后端會遇到系統復雜程度過高的情況，自然前端的業務和互動也會越來越復雜，所以最后前端也需要和后端一起建立 “微服務化” 的體系，
微前端是什么？
微前端的起源和后端一樣，就是一個模塊因為業務和功能的持續發展，導致模塊內容的代碼越來越復雜，越來越龐大，同時就會造成與其他業務有不可避免的互相影響的關系，
就是這些模塊與模塊之間的關系，讓我們的系統變得越來越難以維護，大大減低了開發的 “敏捷性”，
那么怎么辦呢？我們就讓一個大型的 app 的業務，按模塊拆分成一個一個小的 “服務” 模塊，這些小的模塊會與后端的介面一樣，放在單獨的服務器上運行，同時也會有單獨的小團隊進行專門的開發和維護，
這種微型的獨立前端架構體系和系統就叫做 “微前端”，
每個 “微前端” 應用的開發團隊，擁有整個應用的生命周期中的自主性，這就包塊獨立開發、獨立版本號管理、獨立測驗、獨立打包、獨立渲染、獨立更新、獨立部署，
在上面的圖中，我們就可以看到微前端在一個研發中心里的組織架構，每一個微前端團隊都會負責一個獨立的業務模塊，每一個模塊都會有他們自己的核心業務，與其他業務的功能其實是相對獨立的，但是業務的流程上他們就會通過資料流、互動流、介面等方面串聯起來，
最終用戶所體驗到的系統，其實跟我們普通的應用沒有什么區別，但是大型應用的開發和維護的角度來看，就獲得了非常多的好處，
微前端的好處
- 自主性 —— 可以對每一個微前端應用進行獨立的開發、部署、維護和擴展，而不影響其他微前端應用的功能，
- 專用性 —— 每個微前端應用都是針對一組功能而設計的，并專注于解決特定的問題，如果開發者逐漸將更多的代碼增加到一項微前端應用當中，從而讓這個微前端應用變得復雜時，那么我們可以將其再次拆分成多項小的微前端應用，
- 敏捷性 —— 微前端是由若干個小型獨立團隊形成的一個組織，這些團隊負責自己的微前端應用，每個團隊在小型而易于理解的環境中進行開發，并且可以更獨立，更快速地作業，這個縮短了開發周期的時間，
- 靈活擴展 —— 通過微前端化應用，我們可以獨立擴展組件和功能來滿足其他應用的需求，這使團隊能夠適當調整基礎設施需求，準確的衡量功能成本，并在服務需求激增時保持可用性，
- 輕松部署 —— 微前端支持持續集成和持續交付，可以輕松和放心的嘗試新的想法，并可以在無法正常運行時獨立回滾某一個應用，由于微前端應用直接都是獨立的，所以問題只會發生在自己的應用當中，所以我們可以大膽的試驗，更輕松地更新代碼，并縮短新功能的上線時間，
- 技術自由 —— 微前端架構不遵循 “一刀切” 的方法，團隊可以自由選擇最佳的工具或者框架來解決他們的具體問題，也就是說一個微前端應用可能是用 Vue，然后另外一個可能是用 React 也不是不可以的，因此，構建微服務的團隊可以自行選擇最佳的工具或者框架，
- 可重復使用 —— 將前端應用劃分成明確定義的模塊，讓團隊可以將功能用于多種目的，專為某項功能撰寫的前端模塊可以用作另一項功能的構建模塊，這樣應用程式就可以自行引導，因為開發者可以創建新的功能，而無需從頭開始撰寫代碼，
- 彈性 —— 前端應用獨立增加了應用程式應對故障的彈性，在整體式架構中，如果一個組件出現故障，可能導致整個應用程式無法運行，通過微前端的拆分架構，應用程式可以通過降低功能而不導致整個應用程式崩潰來處理總體服務故障，
微前端案例
我們了解了微前端是什么，并且它有什么用，那么我們來看看一個微前端在實際開發場景中是怎么樣的，
這里幻想一下，我們有一個博客的主頁，主要的功能就是為了展示我們的文章內容，當然一個博客其實很簡單，在正常開發場景下，也不會給它做微前端的架構設計，
但是如果我們真的想把它做的更強大，那也是可以的：
- 首先當用戶進入我們的首頁，可以看到文章的串列，并且用戶可以通過關鍵詞來搜索文章，同時也可以通過分類、標簽來搜索，更復雜一點的話，我們還可以根據閱讀量，熱度（通過演算法計算熱度）來排序和搜索，
- 每一篇文章必然會有一個詳情頁，每個詳情頁都需要展示文章的詳細文本，如果我們想加大難度的話，我們還可以根據標簽和用戶日常的文章瀏覽記錄，來推算用戶會對其他什么文章感興趣，這個時候我們就可以加入相關推薦的文章串列了，
- 博客必然就會有博主的介紹頁（About）、文章分類頁（Categories）和文章標簽頁（Tags），
當然這個還不是很復雜，但是當我們繼續往這個博客平臺加入更多的功能，比如最后做成 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）”，比如身份驗證和導航
- 把多個微前端應用放在一個頁面之中，并且告訴每一個微前端應用在什么時候和在哪里渲染到頁面上，
大概的頁面設計如下：
注意我們這里只講到微前端的皮毛，其實微前端最核心并不在前端，更多的難點都是在 “云服務器”，如果沒有服務器架構、部署、測驗和后端介面等等的支撐，微前端是很難以實作的，所以在一般公司的應用場景，其實根本用不上微前端，如果用不上，了解到這里其實已經可以了，到用得上的時候再去深挖更多的知識即可！
「2」原子設計 （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個字符是什么樣子，當用戶的購物車中有一件商品應用了折扣的時候，商品的展示會是怎么樣的，這些實際的情況會影響我們如何回圈和構建我們的應用，
為什么用原子設計理念？
我們簡單理解了原子設計后，我們就可以問問，為什么要用原子設計呢？
其實答案很簡單，我們平時去設計一個應用的時候，即使我們沒有意識去使用這種思維方式，但是我們一直都是以這種方式在設計的，
原子設計為設計系統提供了一種清晰的方式輪（概念為主），團隊成員（開發者、產品經理、設計師等）能夠通過實際看到的，擺在他們面前的步驟來更好地理解設計系統的概念，
原子設計賦予我們從抽象到具體的能力，正因如此，我們可以創建促進一致性和可伸縮性的系統，同時在最終的頁面中顯示內容，
重點是通過組合而不是解耦的方式來構建應用，我們在一開始就創造了一個系統，而不是在事后才去挑選模式，
「3」封裝樣式和 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 并不是一個全新的東西，它已經被瀏覽器使用了很長一段時間了，瀏覽器用它來封裝一個寫元素的內部結構，以一個有著默認播放控制按鈕 <video> 元素為例，
我們所能看到的只是一個 <video> 標簽，實際上，在它的 Shadow DOM 中，包含了一系列的按鈕和其他控制器，Shadow DOM 標準允許我們自己的元素（custom element）維護一組 Shadow DOM，
這種方式也常常被認同為是組件樣式封裝的最佳解決方案，
基本用法
首先我們可以使用 Element.attachShadow() 方法來將一個 shadow root 附加到任何一個元素上，
這個方法接受一個配置物件作為引數，這個物件有一個 mode 屬性，它的值可以是 open 或者 closed：
let shadow = elementRef.attachShadow({mode: 'open'});
let shadow = elementRef.attachShadow({mode: 'closed'});
open： 表示可以通過頁面內的 JavaScript 方法來獲取 Shadow DOM, 例如使用 Element.shadowRoot 屬性：
let myShadowDOM = myCustomElem.shadowRoot;
但是如果我們把 Shadow root 附加到一個自定義元素（Custom element）上，并且把 mode 設定為 closed，那么我們就不可以從外部獲取到 Shadow DOM 了 —— myCustomElem.shadowRoot 將會回傳 null，
其實瀏覽器中的 <video> 就是這樣的，里面就包含了一個不可訪問的 Shadow DOM，
如果你想將一個 Shadow DOM 附加到 custom element 上，可以在 custom element 的建構式中添加如下實作（目前，這是 shadow DOM 最實用的用法）：
let shadow = this.attachShadow({mode: 'open'});
將 Shadow DOM 附加到一個元素之后，就可以使用 DOM APIs 對它進行操作，就和處理常規 DOM 一樣，
var para = document.createElement('p');
shadow.appendChild(para);
詳細的使用方式，可以直接去看 MDN 的 《使用 shadow DOM》，
「4」TypeScript 的崛起
最近也有不少文章講的好像 TypeScript 要一統整個前端江湖，有報告統計，80% 的開發者承認，他們想在下一個專案中使用或者學習 TypeScript，
雖然 TypeScript 還是有它的缺點的，但它讓代碼更容易理解（對于習慣撰寫面向物件的同學，確實好理解，但是不熟悉面向物件的同學，就有點難受了），并且 TypeScript 有利于快速實作，上生產后的 bug 也更少，
那么我們應不應該轉 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，并且都不太愿意去學，或者公司根本給不到時間讓我們團隊去學習新的語言，
那么選擇換這個語言就不是最佳的選擇，
沒有最好的技術，只有最合適當下使用的技術，
「5」Web 組件
Web 組件就是前端的未來， 為什么呢？
因為純 web 組件與任何的前端框架無關，他們可以在沒有框架或者使用任何框架的情況下作業，
因為這些組件更加不受 “JS 疲勞（JavaScript Fatigue）” 所控制，并且大部分瀏覽器都是支持的，
因為它們的包大小和消耗是更有優勢的，加上 VDOM 渲染擁有令人震驚的能力，
這些組件提供了自定義元素、一個 Javascript API （允許我們定義一種新的 html 標記）、html 模板來指定布局，當然還有 Shadow DOM（本質上是特定于組件的），
這里解釋一下什么是 JS 疲勞 —— 就是當我們想學習前端的時候，第一個接觸的語言必然就是 JavaScript，但是一旦開展學習后，就會發現這個水是真的深，一大竄的其他關聯知識就會如同潮水一樣撲面而來，包括，前端框架、Node.js、UI 框架、瀏覽器知識、工具鏈等等，學習前端一開始確實是一個非常疲勞的一個領域，
當我們思考未來 UI 開發，以及模塊化、可重用性、封裝性和標準化的原則時，組件（化）時代應該是怎么樣子時，web 組件就會浮現在未來的藍圖上，
想了解更多關于組件化的知識，可以前往我的組件化系列文章：
- 《前端組件化基礎知識》
- 《用 JSX 建立組件 Parser（決議器）》
這個系列還在持續更新中～
「6」狀態管理：再見 Redux？
無論是 React 的 Redux 還是 Vue 的 Vuex 其實都是特別難搞的大魔頭，盡管隨著前端變得越來越模塊化，在應用程式中的全域狀態管理變得越來越難以控制，但是狀態管理（State Management） 像 Redux 和 Vuex 的實用性和實用性使他們成為許多團隊的首選解決方案，
所以我們在 2020 年之后可以和 Redux 說再見了嗎？不，不完全可以，
然而，在前端框架中開始出現內部狀態管理體系（如 React hook、Context-API 等），未來很有可能會廢除掉對框架以外的狀態管理的依賴，
像 Mobx，一開始這些型別的技識訓很少被采用，但是由于它們面向組件和可延伸性的特性，僅僅在 2020 年這一年內，它們開始變得越來越流行，讓我們開發者可以探索更多的選擇，
想了解更多，可以去了解一下 MobX 的官方檔案，
MobX 是一個經過戰火洗禮的庫，它通過透明的函式回應式編程（transparently applying functional reactive programming - TFRP）使得狀態管理變得簡單和可擴展，MobX背后的哲學很簡單:
- 任何源自應用狀態的東西都應該自動地獲得，
- 其中包括UI、資料序列化、服務器通訊，等等，
「7」ESM CDN
ES 模塊就是在瀏覽器使用模塊時的標準，而 ES 模塊就是被 ECMAScript 所標準化的，使用 ES 模塊，你可以很容易地將功能封裝到模塊中，這些模塊可以通過 CDN 來使用，
隨著 Firefox 60 的發布，所有主流瀏覽器都將支持 ES 模塊，Node mteam 正在努力向 Node.js 中添加 ES 模塊的支持，此外，WebAssembly 的 ES 模塊集成也將在未來幾年內推出，
「8」漸進式網路應用（PWA）
漸進式網路應用也叫 Progressive Web Apps —— 它利用最新的技術將網頁和移動應用程式結合起來，可以把 PWA 想成一個使用 web 技術的網站，但是行為和感覺是一個應用程式（APP），最近在瀏覽器、服務的可用性 worker、Push APIs 的發展與進步，允許了用戶在桌面安裝 web 應用程式，甚至接收推送通知和離線作業，
由于 PWA 提供了親密的用戶體驗，而且所有的網路請求都可以通過 service worker 被攔截，因此，必須將應用托管在 HTTPS 上，從而防止 “中間人” 攻擊，這也意味著更好的安全性，
當然，PWAs 仍然有局限性，它們不能完全替代本地應用，（不過，它們真的需要那么做嗎？）特別是，由于本質上是網頁，PWAs 不能使用大多數硬體功能，如 NFC 和藍牙，然而，并不是所有的應用程式都需要這些功能，
不過 PWAs 開發起來更快、更容易、更便宜，這就是為什么它們在 2020 年成為開發的趨勢，并且在下一年肯定會繼續成為趨勢的原因，
「9」WebAssembly (WASM)
JavaScript 很棒，但是也不是沒有缺點， JavaScript 是存在性能問題的，所有決議型語言都面臨同樣的問題，而 WebAssembly 是解決這個問題的最新途徑，
WebAssembly 最好的一個點是，它并不是一門全新的語言，我們可以用自己喜歡的語言來撰寫，然后將其編譯成 WASM 檔案，以便在瀏覽器中運行，WebAsssembly 目前支持的語言有 C/c++、Elixir、Python、Go、c#/.Net 和 Java，
WebAssembly 不是最近才有的，它已經上市好幾年了，但它發展的迅速，提供了越來越多的選擇，默認情況下，現在所有主流瀏覽器都支持它，如果程式員 能擁有它是一件非常有益的事情，
「10」可訪問性（a11y）
可訪問性，也叫 Accessibility —— 這是 web 應用層序開發中最重要的東西之一，我們相信可訪問性，應該是每一個網站開發者的任務串列中的首要任務，不僅是新網站，而舊網站的更新也是一樣，
可訪問性（或 a11y）是一個計算機系統對用戶的 “方便性” 的考量原則，網站應該能在各種設備上正常運行，但它們應該適用于各種“障礙”和“殘疾”的用戶，A11y 通常指軟體和硬體的可訪問性，
在網頁開發方面，可以透過以下途徑達成易讀性：
- 更大或可自定義的字體大小
- 可選的高對比度的頁面
- 支持語音合成/文本到語音的轉換
- 視頻字母
- 所有語音都附有文本
- 導航語音識別
- 純語言文字
- 突出重要部分
- 一致的導航和盡可能少的步驟
- 簡化授權（但不犧牲安全性）
- 用鍵盤導航，而不是滑鼠/觸控板
- 語意 HTML
a11y 這個名字來自于 “accessibility” 中有 13 個字母，所以在 “a” 和 “y” 之間有 11 個字母，但如果你仔細看，a11y 看起來像 “ally” 這個詞 —— 意思是朋友、助手、拍檔的意思，
「11」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 經歷了許多的重大改進和更新，最終形成了許多開發人員現在所說的，最簡單和最漂亮的框架之一，
「12」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 開發體驗，并且可以快速實作 UI 組件樣式和易于維護，
總結
在 2020 年里面，前端領域依然在高速發展中，新的技術在不停的涌出，已有的技術和框架也在不斷的更新迭代，隨著技術的發展，前端這個領域在 2021 年里面依然會繼續以光速發展，
很多在前端領域的同學在很多群里都會說 “不要再更新啦，不要再出新的框架啦，學不動了～”
所以我們真的所有的新技術都要學嗎？并不是的，重點是我們不要為了技術而技術，而是為了解決問題而學一門新技術，我覺得這個很值得我們深思的，
我反而覺得，重點不是框架那個以后發展更好，而是了解每個框架為什么存在，當下有什么問題導致有了這些框架，以后可能會有什么問題，可能需要什么東西來解決，
說到這里很多同學就會問，“那么我們應該往哪個方面發展呢“ ？
我覺得月影老師說的可以參考：
”基礎和底層知識，基礎和底層知識，基礎和底層知識，”
因為所有框架也好，新技術也好，我們也不確定以后會出來什么，最后哪個可能會一統天下，或者那個會默默的隱退江湖，
所以重點是我們需要學習，保持可以快速上手任何框架和技術的能力，其實無論是 Vue，React，Angular 還是 Flutter，底層不都是 JavaScript 嗎？甚至 Node.js 也是，然后更底層呢？不就是計算機基礎知識嗎？如果我們這些學通透了，那么以后出來什么各種花樣，難道我們不能在一周內學會嗎？（可能不能一周內，但是快速上手還是可以的嘛）
基礎知識還有像數學，這些都是永世不會變的知識，而往往這些知識都是我們開發者的基礎，而這些基礎才是我們真正能適應這個技術高速發展的時代，也是這些基礎讓我們不會害怕任何的變化，因為我們擁有可以適應任何變化的能力，
我們需要關注前端每年的發展、熱點、和趨勢，但是不需要盲目的跟風，甚至去深入學習新的東西，更多是觀望這些科技的發展，了解它們，當我們需要用到它們的時候再去深度學習它們，解決我們當下在專案中遇到的問題，這個才是正確的方向和心態，
我是來自《技術銀河》的三鉆，一位正在重塑知識的技術人，下期再見，
開源專案推薦
Hexo Theme Aurora
最近博主在全面投入開發一個可以 “邁向未來的” Hexo 主題，以極光為主題的博客主題，
如果你是一個開發者，做一個個人博客也是你簡歷上的一個亮光點，而如果你有一個超級炫酷的博客，那就更加是亮上加亮了，簡直就閃閃發光，
如果喜歡這個主題，可以在 Github 上給我點個 🌟 讓彼此都發光吧～
主題 Github 地址：https://github.com/auroral-ui/hexo-theme-aurora
主題使用檔案：https://aurora.tridiamond.tech/zh/
博主開始在B站直播學習，歡迎過來《直播間》一起學習，
我們在這里互相監督，互相鼓勵，互相努力走上人生學習之路，讓學習改變我們生活！
學習的路上，很枯燥，很寂寞，但是希望這樣可以給我們彼此帶來多一點陪伴，多一點鼓勵，我們一起加油吧！ (? ?????)?
專欄推薦
小伙伴們可以查看或者訂閱相關的專欄，從而集中閱讀相關知識的文章哦，
-
?? 《2021年總結》 — 一個一線戰場中的開發者，回歸到學習的學堂中，一開始這個程序確實遇到了挺多困擾的，一開始無法靜心下來學習，因為學習底層的知識確實需要靜下心來學，但是堅持了一段時間后，又會發現自己會愛上學習，愛上深挖這些知識，
-
📖 《前端進階》 — 這里包含的文章學習內容需要我們擁有 1-2 年前端開發經驗后，選擇讓自己升級到高級前端工程師的學習內容（這里學習的內容是對應阿里 P6 級別的內容），
-
📖 《資料結構與演算法》 — 到了如今，如果想成為一個高級開發工程師或者進入大廠，不論崗位是前端、后端還是AI，演算法都是重中之重，也無論我們需要進入的公司的崗位是否最后是做演算法工程師，前提面試就需要考演算法，
-
📖 《FCC前端集訓營》 — 根據FreeCodeCamp的學習課程，一起深入淺出學習前端，穩固前端知識，一起在FreeCodeCamp獲得證書
-
📖 《前端星球》 — 以實戰為線索，深入淺出前端多維度的知識點，內含有多方面的前端知識文章，帶領不懂前端的童鞋一起學習前端，在前端開發路上童鞋一起燃起心中那團火🔥
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/271238.html
標籤：AI
上一篇：Vue 3 生命周期完整指南