透過9個Vue3 元件庫，看看聊前端的流行趨勢！-Vue.js-PHP中文網

這篇文章跟大家分享9個開源的Vue3元件庫，透過它們聊聊發現的前端的流行趨勢，希望對大家有所幫助！

透過9個Vue3 元件庫，看看聊前端的流行趨勢！

參考如下開源元件庫，因為有些設計是多個版本和框架的，這裡只討論 Vue3 版本。（學習影片分享：vue影片教學）

element-plus- 經典中的經典，全面支援Vue 3
#tdesign-vue-next- 鵝廠優質UI 元件，配套工具完滿，設計工整，文件清晰
arco-design-vue- 位元組跳動UI 元件庫開源，大廠邏輯，設計文件完美
ant-design-vue# - 螞蟻前端UI 庫，面向企業級中後台
naive-ui- 寶藏Vue UI 庫，Vue UI 新星，從Vue 3 開始
#vant- 有讚團隊開源移動UI 元件庫，全面支援Vue 3
##nutui- 京東出品，移動端友好，面向電商業務場景
vuetify- 老牌Vue UI ，基於Google的Material Design 樣式開發
#varlet- Varlet 是一個基於Vue3開發的Material 風格行動裝置元件庫，全面擁抱Vue3生態，由社群建立起來的元件庫團隊進行維護。

名稱 TypeScript Monorepo 套件管理器 esbuild SVG Icon CSS 變數 #element-plus true



		#true	pnpm	true	true	#true scss
tdesign-vue-next	true	submodule	沒有lock文件，npm	true	true svg & iconfont	true less
arco-design-vue	true	#true	yarn	vite預設true	true	false less
ant-design-vue	true	false	沒有lock文件，npm	true	true	true less
#naive-ui	#true	false	沒有lock文件，npm	true	#true xicons	#一個全新模式
vant	true	true	pnpm	true	false iconfont	true less
nutui	true	false	#沒有lock文件，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%
這個流行趨勢已經成必然了，現在面試也有越來越多的 TS 相關。

rollbar 是一個異常監控平台，rollbar 在2018 年統計了前端專案中Top10 的錯誤類型：

透過9個Vue3 元件庫，看看聊前端的流行趨勢！

# #這裡有很多錯誤都是空的或未定義的。如果使用 TypeScript 就可以簡單的避免這些錯誤。

使用TypeScript可以避免 80% 的相關錯誤，當然

anyScript

不行。。另外

TypeScript

的優勢不只如此，例如 IDE 的智慧提示，專案更容易維護等等。如果你還沒用過過 TS，那最好現在就開始嘗試使用。

Monorepo

流行度：55%

包括vue、Reac、Babel等越來越多的專案都開始使用

Monorepo

透過9個Vue3 元件庫，看看聊前端的流行趨勢！

#Monorepo，就是指將所有程式碼放到一個程式碼倉庫中的專案管理策略。

Monorepos 的優點

：共享依賴，所有的程式碼都在一個倉庫。版本管理非常方便。
：所有的程式碼都在一個倉庫，很容易抽離出各個專案共用的業務元件或工具，並透過 TypeScript 在程式碼內引用。
：所有程式碼在一個倉庫，程式碼品質標準和統一風格會更容易。

：所有人都能看到全部程式碼，跨團隊協作和貢獻更容易。

Monorepos 的缺點

#效能：程式碼越來越多，
之類的工具會越來越卡牌。權限：管理檔案權限會更具挑戰，
目錄並沒有內建的權限管理系統，整個專案是沒辦法區分某些部門開放哪個項目，某些部門關閉的。

：對新人來說，專案變大了，學習成本自然會更高。

Monorepo 絕對不是銀彈，Monorepo 策略也不完美，但某些方面來說確實解決了一些專案的維護和開發體驗。如果你的專案有多個關聯倉庫，或者還在用submodule方式管理多個倉庫，那可以試試看

Monorepo

。

套件管理器

有55%使用非npm，剩下45%看不出來使用什麼套件管理工具，最主要的是居然都沒有

lock

文件，這個是真沒看懂，作為開源專案不需要統一依賴版本的嗎？

npm v1-v2

第一代的
npm
因為是樹型結構，
node_modules

npm v3 / yarn

#從npm3和

yarn

開始，都會透過扁平化依賴的方式來解決上面的這個問題。所有的依賴都被拍平到node_modules目錄下，不再有很深層的巢狀關係。這樣在安裝新的套件時，根據node require機制，會不停往上級的

node_modules

當中去找，如果找到相同版本的套件就不會重新安裝，解決了大量套件重複安裝的問題，而且依賴層級也不會太深。

幽靈依賴-
package.json###裡並沒有寫入的套件竟然也可以在項目中使用了。 ###
分身依賴- 例如A 和B 都依賴了C，但是依賴C的版本不一樣，一個是1.0.0，一個是2.0.0。這時取決於A 和B 在package.json中的位置，使用的C有可能是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現存生態，相容性不太好。

pnpm

pnpm具有安裝速度快、節省磁碟空間、安全性好等優點，它的出現也是為了解決npm和yarn存在的問題。

1、pnpm透過硬連結與符號連結結合的方式，來解決yarn與npm的問題。

硬連結：硬連結可以理解為原始檔案的副本，pnpm會在全域store儲存項目node_modules檔案的硬連結。硬連結可以使得不同的項目可以從全域store尋找到同一個依賴，大大節省了磁碟空間。
軟體連結：軟連結可以理解為捷徑，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 ==>  /B └── A@1.0.0 └── node_modules ├── B --> ../../B@1.0.0/node_modules/B └── A ==>  /A

登入後複製

-->代表軟鏈接，==》代表硬鏈接

##而這種嵌套

node_modules結構的好處在於只有真正在依賴項中的套件才能訪問，很好地解決了幽靈依賴的問題。此外，因為依賴總是存在store目錄下的硬鏈接，相同的依賴總是只會被安裝一次，多重依賴的問題也得到了解決。

2、當然

pnpm也存在一些限制。

pnpm-lock.yaml和package-lock.json不一致，不能相容。
Electron。
patch-package之類的工具也不能用了。

雖然還有種種問題，但整體來說瑕不掩瑜。

其他

ni可以理解為套件管理器的管理器，ni假設您使用鎖定檔案（並且您應該），在它運行之前，它會檢測你的yarn.lock/pnpm-lock.yaml/package-lock.json以了解當前的套件管理器，並執行相應的命令。

cnpmcnpm和npm以及yarn之間最大的差異就在於產生的node_modules目錄結構不同，這在某些場景下可能會引發一些問題。另外也不會產生lock檔案。但是cnpm保持了node_modules的目錄結構清晰，可以說是在巢狀模式和扁平模式之間找到了一個平衡。

很多面試會問pnpm 為啥快，除了上面的
store保證全域只安裝一次，還有軟連線保證不重複安裝之外。還有一個，當安裝同一依賴的不同版本時，只有不同的部分會被重新保存。

建議不管用什麼套件管理工具，都要加上lock文件，在版本更新期間去升級依賴。以便能獲得更好的安全性。

esbuild

流行度：89%

##esbuild是用go語言寫的javascript、typescript打包工具，速度比webpack快100倍以上。

雖然打包工具用的各不相同，有

vite、webpack、Rollup，但最後都用到了esbuild打包。只有一個vuetify沒用，不過vuetify還還沒正式發布，後面也說不定會換。

未來

ESM標準會越來越流行，所以相對應的工具鏈也會越來越流行。

vite 嚴格來說不是打包工具，而是一個前端建置工具，vite 實際使用 Rollup 和 esbuild 來打包。

SVG Icon

流行度：55％

關於

Icon Font的缺陷，可以看這篇Inline SVG vs Icon Fonts文章。主要有以下幾個方面：

瀏覽器將其視為文字進行抗鋸齒優化，有時得到的效果並沒有想像中那麼銳利。尤其是在不同系統下對文字進行抗鋸齒的演算法不同，可能會導致顯示效果不同。
Icon Font作為一種字體，Icon顯示的大小和位置可能要受到font-size、line-height、word-spacing等等CSS 屬性的影響。Icon所在容器的CSS樣式可能會對Icon的位置產生影響，調整起來很不方便。
使用上有不便。首先，載入一個包含數百圖標的
Icon Font，卻只使用其中幾個圖標，非常浪費載入時間。自己做Icon Font以及把多個Icon Font中用到的圖示整合成一個Font也非常不方便。
為了實現最大程度的瀏覽器支持，可能要提供至少四種不同類型的字體檔案。包括
TTF、WOFF、EOT以及一個使用 SVG 格式定義的字體。
網路延時會導致
Icon會先載入出來一個string。