今天在微信群討論了很多Blazor是否可以正常用的問題。大家爭的面紅耳赤的。
於是趁著無聊，就水了這麼一篇文。
還記得Blazor還在預覽版的時候，我就開始關注Blazor了。
那會兒除錯Blazor還得在瀏覽器位址列輸入一堆命令，除錯都賊不方便。打包出來也是很大，瀏覽器也很卡頓。
可以從以下幾個方面來說一下為什麼我認為Blazor可以在小規模的正式環境中使用。以及哪些地方不太適用Blazor
1.包大小
但是如今幾年過去了。Blazor從一開始的一堆好幾M的庫，到現在5.0版本
Hello World的包大小已經縮減到一百多kb左右了。當然現在依然沒法和Vue NG這樣的能縮減到50kb以下的框架來比。（這點大小我認為不影響框架載入速度）
2.功能對比
一個優秀的SPA框架，各方面也要優秀。我們可以使用Blazor對比一下Vue.js的功能。
| Vue.js | Blazor | |
|---|---|---|
| 模板 | 支援 | 支援 |
| 狀態管理 | 支援 | 不支援 |
| 動畫元件 | 支援 | 不支援 |
| 路由元件 | 支援 | 支援 |
| 元件庫數量 | 多 | 少 |
| 元件庫質量 | 高 | 低 |
| 使用人數 | 多 | 少 |
| 伺服器渲染 | 支援 | 支援 |
| 外掛 | 多 | 少 |
以上對比來自己我個人的主觀使用。
.NET 5.0讓我覺得眼前一亮的是提供一個虛擬滾動元件：Virtualize 這個功能Vue.js至今沒有官方實現。但是Blazor居然提供了。這裡要給微軟點個贊。
3.適用場景以及不適用的場景
從Blazor的文件來看，Blazor基本沒有對老舊瀏覽器有一個良好的支援。
瀏覽器環境
如果有需要相容IE10或者11+版本的需求，不要選擇Blazor。不挑選瀏覽器環境的話，可以選擇Blazor。移動端 TO b專案可以選擇Blazor。 To c慎重（畢竟to c客戶不能要求別人換瀏覽器）
CSS功力
為什麼我會有提出這個點呢？因為Blazor的UI元件庫質量一言難盡。
-
Element-blazor處於斷更狀態。幾個月沒更新了。
-
Ant-blazor的官網都隨時掛掉。元件也賊卡頓。
-
唯一感覺質量還行的BootStrapBlazor，UI風格有點太老。需要自己調整CSS。（如果對介面要求不高的，可以使用。）
用Blazor的需要什麼特殊功能的元件的話（如顏色選擇器，Cron選擇器），一般找不到合適的第三方。需要自己動手解決寫元件的問題。
很多長期做純後端工作的老鐵們都覺得寫CSS很費勁。實際上並不是，大約在去年7月之前，我也是一個CSS小菜雞。但是去年不知道腦子抽什麼風。想用自己弄一套元件庫出來。於是重溫CSS，閒暇時間也擼了幾十個感覺還行的元件庫（後期會開源，基於Vue.js寫的）
總結
如果你正在做一個內部使用的簡單後臺系統，那完全沒問題。如果你要做一個很複雜且要長期維護的專案，建議等Blazor的進一步優化。
歡迎關注我的公眾號 ：qingchengcoding
一個以ASP.NET Core+Vue.js的Web開發知識的公眾號
