看了九個開源的 Vue3 組件庫，發(fā)現(xiàn)了這些前端的流行趨勢
參考了如下組件庫，因為有些設計是多個版本和框架的，這里只討論 Vue3 版本。
- element-plus [3] - 經(jīng)典中的經(jīng)典，全面支持 Vue 3
- tdesign-vue-next [4] - 鵝廠優(yōu)質 UI 組件，配套工具完滿，設計工整，文檔清晰
- arco-design-vue [5] - 字節(jié)跳動 UI 組件庫開源，大廠邏輯，設計文檔完美
- ant-design-vue [6] - 螞蟻前端 UI 庫，面向企業(yè)級中后臺
- naive-ui [7] - 寶藏 Vue UI 庫，Vue UI 新星，從 Vue 3 起步
- vant [8] - 有贊團隊開源移動 UI 組件庫，全面支持 Vue 3
- nutui [9] - 京東出品，移動端友好，面向電商業(yè)務場景
- vuetify [10] - 老牌 Vue UI ，基于谷歌的 Material Design 樣式開發(fā)
- varlet [11] - Varlet 是一個基于 Vue3 開發(fā)的 Material 風格移動端組件庫，全面擁抱 Vue3 生態(tài)，由社區(qū)建立起來的組件庫團隊進行維護。
名稱 | TypeScript | Monorepo | 包管理器 | esbuild | SVG Icon | CSS 變量 |
element-plus | true | true | pnpm | true | true | true scss |
tdesign-vue-next | true | submodule | 沒有l(wèi)ock文件，npm | true | true svg & iconfont | true less |
arco-design-vue | true | true | yarn | vite默認 true | true svg & iconfont | true less |
ant-design-vue | true | false | 沒有l(wèi)ock文件，npm | true | true svg & iconfont | true less |
naive-ui | true | false | 沒有l(wèi)ock文件，npm | true | true xicons | true, 一個全新模式 |
vant | true | true | pnpm | true | false iconfont | true less |
nutui | true | false | 沒有l(wèi)ock文件，npm | vite默認 true | false iconfont | false scss |
vuetify | true | true | yarn | false | false iconfont | true |
varlet | true | true | pnpm | vite默認 true | false iconfont | true |
TypeScript
流行度：100%
這個流行趨勢已經(jīng)成必然了，現(xiàn)在面試也有越來越多的 TS 相關。
rollbar 是一個異常監(jiān)控平臺，rollbar 于 2018 年統(tǒng)計了 前端項目中Top10 的錯誤類型 [12] ：
這里有很多錯誤都是空的或未定義的。如果使用 TypeScript 就可以簡單的避免這些錯誤。
使用 TypeScript 可以避免 80% 的相關錯誤，當然 anyScript 不行。。
另外 TypeScript 的優(yōu)勢不止于此，比如 IDE 的智能提示，項目更容易維護等等。如果你還沒有用 過 TS，那最好現(xiàn)在開始嘗試使用。
Monorepo
流行度：55%
包括 vue、Reac、Babel 等越來越多的項目都開始使用 Monorepo
Monorepo，就是指將所有代碼放到一個代碼倉庫中的項目管理策略。
Monorepos 的優(yōu)點
- 依賴管理：共享依賴，所有的代碼都在一個倉庫。版本管理非常方便。
- 代碼復用：所有的代碼都在一個倉庫，很容易抽離出各個項目共用的業(yè)務組件或工具，并通過 TypeScript 在代碼內引用。
- 一致性：所有代碼在一個倉庫，代碼質量標準和統(tǒng)一風格會更容易。
- 透明度：所有人都能看到全部代碼，跨團隊協(xié)作和貢獻更容易。
Monorepos 的缺點
- 性能 ：代碼越來越多， Git、IDE 之類的工具會越來越卡。
- 權限 ：管理文件權限會更具挑戰(zhàn)， Git 目錄并沒有內置的權限管理系統(tǒng)，整個項目是沒辦法區(qū)分某些部門開放哪個項目，某些部門關閉的。
- 學習成本：對新人來說，項目變大了，學習成本自然會更高。
Monorepo 絕對不是銀彈，Monorepo 策略也不完美，但某些方面來說確實解決了一些項目的維護和開發(fā)體驗。
如果你的項目有多個關聯(lián)倉庫，或者還在用 submodule 方式管理多個倉庫，那可以試一試 Monorepo 。
包管理器
有 55% 使用 非npm ，剩下 45% 看不出來使用什么包管理工具，最主要的是居然都沒有 lock 文件，這個是真沒看懂，作為開源項目不需要統(tǒng)一依賴版本的嗎？
npm v1-v2
- 初代的 npm 會導致重復安裝依賴，比如 A 依賴 C，B 也依賴 C，這時會安裝兩次 C。(是安裝兩次，不是下載兩次。會下載到本地緩存。)
- 因為是樹型結構， node_modules 嵌套層級過深(會導致文件路徑過長的問題)
- 模塊實例不能共享。比如 React 有一些內部變量，在兩個不同包引入的 React 不是同一個模塊實例，因此無法共享內部變量，導致一些不可預知的 bug。
npm v3 / yarn
從 npm3 和 yarn 開始，都來通過扁平化依賴的方式來解決上面的這個問題。
所有的依賴都被拍平到 node_modules 目錄下，不再有很深層次的嵌套關系。這樣在安裝新的包時，根據(jù) node require 機制，會不停往上級的 node_modules 當中去找，如果找到相同版本的包就不會重新安裝，解決了大量包重復安裝的問題，而且依賴層級也不會太深。
但同時，這樣也帶來了新的問題
- 幽靈依賴 - package.json 里并沒有寫入的包竟然也可以在項目中使用了。
- C 1.0.0 2.0.0package.jsonC 1.0.0 2.0.0
- 平鋪減少安裝沒有減省時間，因為算法的原因，時間居然還增加了。
npm v5 / yarn
該版本引入了一個 lock 文件，以解決 node_modules 安裝中的不確定因素。這使得無論你安裝多少次，都能有一個一樣結構的 node_modules 。
然而，平鋪式的算法的復雜性，幽靈依賴之類的問題還是沒有解決。
yarn v2 PnP
在 yarn 的 2.x 版本重點推出了 Plug’n’Play（PnP） 零安裝模式，放棄了 node_modules ，更加保證依賴的可靠性，構建速度也得到更大的提升。
yarn 2.x 擺脫 node_modules ，安裝、模塊速度加載快；所有 npm 模塊都會存放在全局的緩存目錄下，避免多重依賴；嚴格模式下子依賴不會提升，也避免了幽靈依賴。
但是，自建 resolver 處理 Node require 方法，脫離Node現(xiàn)存生態(tài)，兼容性不太好。
pnpm
pnpm 具有安裝速度快、節(jié)約磁盤空間、安全性好等優(yōu)點，它的出現(xiàn)也是為了解決 npm 和 yarn 存在的問題。
1. pnpm 通過硬鏈接與符號鏈接結合的方式，來解決 yarn 和 npm 的問題。
- 硬鏈接 ：硬鏈接可以理解為源文件的副本， pnpm 會在全局 store 存儲項目 node_modules 文件的硬鏈接。硬鏈接可以使得不同的項目可以從全局 store 尋找到同一個依賴，大大節(jié)省了磁盤空間。
- 軟鏈接 ：軟鏈接可以理解為快捷方式， pnpm 在引用依賴時通過符號鏈接去找到對應磁盤目錄（.pnpm）下的依賴地址。
比如 A 依賴 B，A 下面是沒有 node_modules 的，而是一個軟鏈接。實際真正的文件位于 .pnpm 中對應的 A@1.0.0/node_modules/A 目錄并硬鏈接到全局 store 中。
而 B 的依賴存在于 .pnpm/B@1.0.0/node_modules/B 。
而 A 依賴的 B，用軟鏈接鏈到 上面的地址 ，也就是 B \--> ../../B@1.0.0/node_modules/B
node_modules
├── A --> .pnpm/A@1.0.0/node_modules/A
└── .pnpm
├── B@1.0.0
│ └── node_modules
│ └── B ==> <store> /B
└── A@1.0.0
└── node_modules
├── B --> ../../B@1.0.0/node_modules/B
└── A ==> <store> /A
復制代碼
--> 代表軟鏈接， ==》 代表硬鏈接
而這種嵌套 node_modules 結構的好處在于只有真正在依賴項中的包才能訪問，很好地解決了幽靈依賴的問題。此外，因為依賴始終都是存在 store 目錄下的硬鏈接，相同的依賴始終只會被安裝一次，多重依賴的問題也得到了解決。
- 當然 pnpm 也存在一些局限。
- pnpm-lock.yaml 和 package-lock.json 不一致，不能兼容。
- 一些場景不兼容，比如 Electron 。
- 不同應用的依賴是硬鏈接到同一份文件，所以不能直接修改依賴文件，否則會影響其他項目。而且因為安裝結構不同，原來的 patch-package 之類的工具也不能用了。
雖然還有種種問題，但總體來說瑕不掩瑜。
其他
ni可以理解為包管理器的管理器， ni 假設您使用鎖文件（并且您應該），在它運行之前，它會檢測你的 yarn.lock / pnpm-lock.yaml / package-lock.json 以了解當前的包管理器，并運行相應的命令。
cnpm cnpm 和 npm 以及 yarn 之間最大的區(qū)別就在于生成的 node_modules 目錄結構不同，這在某些場景下可能會引發(fā)一些問題。此外也不會生成 lock 文件。但是 cnpm 保持了 node_modules 的目錄結構清晰，可以說是在嵌套模式和扁平模式之間找到了一個平衡。
很多面試會問 pnpm 為啥快，除了上面的 store 保證全局只安裝一次，還有 軟連接 保證不重復安裝之外。還有一個，當安裝同一依賴的不同版本時，只有不同的部分會被重新保存。
建議不管用什么包管理工具，都要加上 lock 文件，在版本更新期間去升級依賴。以便能獲得更好的安全性。
esbuild
流行度：89%
esbuild 是一個用 go 語言寫的 javascript、typescript 打包工具，速度比 webpack 快 100 倍以上。
雖然打包工具用的各不相同，有 vite 、 webpack 、 Rollup ，但最終都用到了 esbuild 打包。只有一個 vuetify 沒用，不過 vuetify 還沒有正式發(fā)布，后面也說不定會換。
未來 ESM 標準會越來越流行，所以相對應的工具鏈也會越來越流行。
vite 嚴格來說不是打包工具，而是一個前端構建工具，vite 實際使用 Rollup 和 esbuild 打包。
SVG Icon
流行度：55%
關于 Icon Font 的缺陷，可以看這篇 Inline SVG vs Icon Fonts [13] 文章。主要有以下幾方面：
- 瀏覽器將其視為文字進行抗鋸齒優(yōu)化，有時得到的效果并沒有想象中那么銳利。尤其是在不同系統(tǒng)下對文字進行抗鋸齒的算法不同，可能會導致顯示效果不同。
- Icon FontIconfont-sizeline-heightword-spacingIcon CSS Icon
- Icon FontIcon FontIcon FontFont
- TTF WOFF EOT
- 網(wǎng)絡延時會導致 Icon 會先加載出來一個 string 。
SVG Icon 的優(yōu)勢可以用組件文檔的描述
- 完全離線化使用，不需要從 CDN 下載字體文件，圖標不會因為網(wǎng)絡問題呈現(xiàn)方塊，也無需字體文件本地部署。
- 在低端設備上 SVG 有更好的清晰度。
- 支持多色圖標。
- 對于內建圖標的更換可以提供更多 API，而不需要進行樣式覆蓋。
SVG Icon 的劣勢，比如兼容性。（IE：啥？）
當然總體來說， Icon Font 對性能的影響沒有那么大。這也可能是沒那么流行的原因？
CSS變量
流行度：88%
雖然編寫還是使用的預處理語言，但是最后都想辦法轉成了 CSS var 。就性能來說，肯定是瀏覽器支持的 W3C 規(guī)范更好。
但是目前很多預處理語言的函數(shù)之類的功能，原生還不是很好的支持。所以預處理語言還很有存在的必要的。
好了，這就是本篇文章的全部內容了，感謝大家的觀看。
我是一個努力成長的前端菜狗子。
