導讀

blazor是個極好的東西, 如果微軟的 blazor 路線貫徹實施下去，將會是截至目前為止最優(yōu)秀的全棧解決方案。

blazor 生態(tài)包括 blazor server/blazor wasm/maui+blazor。其中，blazor server 是最簡單粗暴的，這玩意開發(fā)用戶量不多的 web 應用速度天下第一快，比第二快的快很多的那種快，能把其他解決方案甩到看不見。搭配一套熟悉的ui框架，開發(fā)速度跟他娘的畫原型圖速度差不多，甚至比畫原型圖還快。

當有個需求，直接上 blazor server，可以以極快的速度搞個可以跑的東西出來。用戶量幾百幾千都扛得住，套個殼可以搞成桌面程序。這個程序可以抗住需求驗證和小規(guī)模推廣階段，當有更多需求時，可以考慮拆成前后臺，ui 代碼大部分可以復用，弄到 blazor wasm，maui+blazor，前臺就可以跨瀏覽器，桌面，移動設備，改動不大。

1、blazor 技術的實質

blazor 的技術實質是使用 html/css 來繪制界面，但是使用 C# 語言來互動操作而并非 js 語言來進行互動操作。C# 語言相對于 js 帶巨大的生產力提升，哪怕是相對于 typescript ，生產力的提升也非常大。

因為使用 C# 得有個運行時。運行時放在服務器端的，叫 blazor server。運行時用 wasm 實現(xiàn)的，叫 blazor wasm。運行時扔給 MAUI，是 blazor maui （這個我沒實際用過，猜的）。

當然，運行時還可以往 winform，wpf，avalonia 等上放。

2、blazor server

這是幾種 blazor 里我最喜歡的，用之前覺得它很垃圾，越用越喜歡。

它的運行時在服務器端，跟 asp.net 在一起，前端的互動會通過 websocket 發(fā)給后端，后端的響應會傳遞給前端進行 ui 的更新。這里不用過多考慮前后端咋通訊的，微軟封裝的特別好，使用體驗非常棒。

從技術角度來說，blazor server 有兩個缺點：

（a）由于UI響應操作是服務器端進行的，網絡的延時會影響 UI 體驗；

（b）服務器承擔了相比傳統(tǒng)web程序多的計算量，服務器端的壓力要大一點。

對于缺點（a），如果你的用戶跟服務器距離的不遠，比如，就是局域網用，或同城用，或者就國內用，體驗度還可以，而全球的話，體驗就不行了。

對于缺點（b），現(xiàn)在服務器硬件越來越強大，越來越便宜，寫的時候稍微注意點，一臺服務器也能抗幾百人、幾千人同時用，更多的就不好說了。也就是說，相同的硬件，抗的人數(shù)較傳統(tǒng)的技術抗的人數(shù)要低。

在能規(guī)避這兩個缺點的地方，它就是王炸。

它的優(yōu)點：在所有 web 開發(fā)技術中 ，它是生產力最高，出東西最快的。前端拖一個 css ui 框架，Ant Design Pro 這種，后端用 Lite DB 這樣的純 .net 的文檔數(shù)據(jù)庫，生產力簡直是狂霸酷帥龍傲天，在座的（其它技術）都是垃圾。生產力的提升不是一倍兩部，而是三倍五倍這種。

傳統(tǒng)的 web 開發(fā)，要考慮 UI，要考慮服務器，要考慮 UI 和服務器的交互，這里 UI 和服務器的交互是兩個機器間的交互，可他娘的復雜了。但是 blazor server 里，UI 雖然是在瀏覽器端展現(xiàn)的，但是 UI 和服務器端交互是在服務器進程里的，直接在內存里開干。

blazor server 的潛力非常大。大家體驗過通過遠程桌面遠程辦公沒？我放了一臺很強的外星人臺式機在家里，通過反向代理遠程桌面練上去，辦公體驗已經非常不錯了。這種模式，就是應用在遠程跑，UI渲染在服務器端，通過視頻流傳到遠程控制端。現(xiàn)在的云電腦，還有云游戲，也都是這種模式。服務器端渲染把畫面?zhèn)鞯娇蛻舳苏宫F(xiàn)。這屬于最重的服務器渲染的搞法，而 blazor server 在技術上，可以看作這種模式的輕量級實現(xiàn)，他將渲染指令通過 html 的方式，發(fā)送給瀏覽器來展現(xiàn)，無論響應速度還是對帶寬的要求，還是對服務器的壓力，都小得多。

隨著網絡的進一步發(fā)展，云電腦、云游戲用的人會越來越多，比這兩種技術輕量得多的 blazor server ，也會有一些獨特的應用場景。這是一個介于 web 程序和云電腦之間的生態(tài)位，這個生態(tài)位還沒有人占，至于會涌現(xiàn)出什么樣的新產品，我他娘的也想不出來，得讓子彈飛幾年。

我也只有一些想法。比如，要開發(fā)在線視頻編輯這種應用，完全在 web 端在線編輯視頻，受到技術限制體驗會很差，用 blazor server，可以突破這個限制。在服務器端進行渲染，web 端只做顯示和交互轉發(fā)。這個要基于 webrtc 來做，還沒有封裝好的控件。在這個架構下，很多傳統(tǒng)的重量級應用可以搬到 web 上了。

拋開上面這種還需要探索的新場景不提，看看現(xiàn)在 blazor server 可以干的事情：

（a）0-1 階段的新產品開發(fā)。新產品開發(fā)存在巨大不確定性，需要以最快的速度搞個可以看到東西來消除不確定性。傳統(tǒng)搞法是產品經理畫原型圖，然后就原型圖討論確定做還是不做。做的話，再讓開發(fā)來搞。就我的體驗，中后臺型產品，直接用 blazor server + Ant Design Pro + LiteDB 搭一個看著很漂亮，具備真實交互邏輯的原型，它的速度幾乎和用 Axure 等工具畫原型圖一樣快?？梢苑浅？斓母銈€原型出來討論，討論通過決定做了，得了，這不已經做出來了嘛 …… 還開發(fā)個毛線啊。直接上手用，哪里出現(xiàn)了限制，咱再改。

（b）局域網程序或同城Web應用開發(fā)。這種情況下，用戶量不多，又都很集中，可以完美避開 blazor server 的缺點。這里提一個小的應用場景，比如，你開發(fā)了一個 web 系統(tǒng)，在 linux 下跑，要做內部用的可視化運維工具，blazor server 就非常合適。

（c）桌面程序。.net 程序現(xiàn)在打包非常容易，開發(fā)完了直接把 server 打包，用 electron 或者什么的包一下，就是桌面程序了。

現(xiàn)階段，blazor server 在論證新產品這塊，具有非常大的優(yōu)勢。在中小型企業(yè)（一半都不跨城吧）、大型企業(yè)內部應用領域，具有非常大的優(yōu)勢。在開發(fā)桌面程序，具有一定的優(yōu)勢。而在未來，開發(fā)類似于云游戲這種服務器渲染的新應用，具備技術優(yōu)勢。它是當前最完美的 baby 階段產品開發(fā)技術。用 blazor server，你能以最快速度開發(fā)出產品，這個產品能在 server 端跑，能在桌面上跑。放服務器端跑的話，還他娘的天生帶了反破解、反爬蟲的特性。一個半吊子懂點產品的C#程序員，可以一個人當三個人用 - 產品經理 + 前端 + 后端。

因為 blazor wasm 和 blazor maui 還沒成熟，blazor server 是我現(xiàn)在最提倡的 blazor 使用模式，當然，互聯(lián)網公司沒法用，用戶量大，服務全球用戶，恰恰踩住了 blazor server 的兩個缺點，而互聯(lián)網程序員的話語權比較大，所以在網上，看不到啥人吹 blazor server 的。

3、blazor wasm

blazor 將運行時放在 wasm 里，缺點就是尺寸比較大，怎么也有幾M。在現(xiàn)階段來說，還是有些大。目前默認 wasm 下跑的 C# 是以解釋的方式跑的，性能較 js 要低得多，AOT 速度塊，但是整體還不夠成熟。而隨著網速越來越快，AOT 成熟后，blazor wasm 的應用場景會增多。blazor wasm 是網上討論最多的 blazor。它相對于傳統(tǒng)的前端后端分離開發(fā)來說，解決了 C# 寫前端的問題，可以提升前端開發(fā)的效率。AOT 成熟后，可以在瀏覽器端跑部分高性能應用。缺點就是，現(xiàn)在速度還不夠快，瀏覽器要加載運行時，會導致加載時間比較長。

由于 C# 程序員稀缺，以及 js 前端程序員及生態(tài)的泛濫，這里的前景，我不是很看好。js 三大框架 + springboot 的生態(tài)優(yōu)勢太強大了。而 blazor wasm 現(xiàn)階段，也沒法開發(fā)小程序，也會影響采用。

未來可期，未來有多遠，還不清楚。

4、blazor maui

blazor maui 就相當于把 electron 用 maui 替代了，由于 maui 自身就是 C# 程序，它就可以成為 blazor 的宿主，asp.net 那塊也沒必要要了（沒看具體實現(xiàn)，我是這么猜的）。

可以把它看成 maui + blazor，也可以看成 blazor + maui。看成前者的話，blazor 為 maui 提供了 web ui 技術?？闯珊笳叩脑挘琺aui 為 blazor 提供了寄宿環(huán)境，可以直接和本地交互。而 maui 是跨平臺的，這一來，一套代碼，在桌面端和在移動端都能跑。

blazor maui 等于 blazor server 和 blazor wasm 的演化。對于 blazor server 來說，它等于將運行時從遠程給放在本地了。對于 blazor wasm 來說，它等于將解釋環(huán)境變成了本地編譯環(huán)境。可以用它來做沒 server 的程序，也可以用它來做有 server 的程序。

blazor maui 是我比較看好的。但由于 vs 正式版還沒把它集成進來，我沒怎么實際用過。上面這些技術細節(jié)是推測的，有錯誤地方，還請指正。

5、總結

我看好 blazor server 和 blazor maui。

要采納一個技術，它必須相比現(xiàn)有技術有不可替代的優(yōu)勢。

blazor wasm 在現(xiàn)階段很難說服大家去用。

blazor server 在產品 baby 階段有非常強的生產力優(yōu)勢，成本的投入也較其他技術要低得多。錢少、事急是 baby 階段重要特征，blazor server 可以解決這兩個痛點，并且，為后續(xù)發(fā)展提供了一個很清晰的演化路徑：

（a）使用 blazor server 進行產品論證；

（b）產品論證完了，就放出去可以直接用了，用戶不接受，直接 GAME OVER；

（c）用戶沒意見，掏腰包付錢；

（d）用戶需要桌面版程序：現(xiàn)階段用 electron 之類的包一下發(fā)出去；等 blazor maui 成熟后，用 maui 包一下發(fā)出去；

（e）產品突然爆火了：將 blazor server 代碼，抽離出 Restful 接口出來，如果 blazor wasm 可行，用 blazor wasm 寫下前端，如果不可行，用 vue.js 之類的寫下前端。后端改動很少。原產品繼續(xù)跑著，等新產品開發(fā)出來后，直接切換升級。

（f）產品要提供原生移動端工具：用 maui 包一下發(fā)布。

如果做 Web 產品，當 blazor server 扛不住了：blazor server -> 前后端分離 -> blazor wasm + asp.net / js + asp.net；

如果做 移動 產品：blazor server -> blazor maui；

如果做 桌面產品：blazor server -> blazor + electron / blazor maui;

如果做全制霸的產品，幾個路徑一起推進，整個路徑很平滑。就算不考慮 C# 強大的生產力，整個技術架構也是有最多的共享代碼，最節(jié)省人力的。