大家好，我是沙漠盡頭的狼。
在 Dotnet9 上線線上小工具和小遊戲後，伺服器的壓力感覺挺大的，打開25個頁面，記憶體佔用約170MB，CPU保持在60~70%，看來Server真的不適合搞這類互動較多的程式（伺服器配置：2核4G記憶體），所以站長加急上線 Blazor Wasm 版本網站，便於大家直觀對比了解兩種模式的區別，下面請看我細說。
1. 關於上線Dotnet工具箱
為了後面工具和遊戲的擴展，站長把去年買的域名 dotnetools.com 用上了，該域名一次性買了10年（不用擔心網站過幾年消失，當然不排除意外，比如站長沒錢續費伺服器...），並趕緊在1天之內開發並部署了一個 Blazor Wasm 版本網站，把在 Dotnet9 已經上線的線上小工具和遊戲同步搬過來了，大家可以體驗下：https://dotnetools.com：
2. Dotnet工具箱網站開源的
網站原始碼組織結構如下，只有一個工程，為了快速上線，程式碼也比較清晰明瞭：
網站原始碼連結在文末，別再問我原始碼位址了。。。。
3. Blazor Server為什麼不適合開發線上工具或遊戲之類的網站應用？
Blazor Server 不適合開發線上工具或遊戲之類的網站應用，主要是因為它的工作原理和特性導致了一些限制和不適用的情況。
即時性限制：Blazor Server 使用了 SignalR 技術來實現與伺服器的即時通訊，但由於所有的 UI 更新都需要透過伺服器來完成，因此在網路延遲較高的情況下，使用者可能會感受到明顯的延遲。這對於線上工具或遊戲等需要即時回應的應用來說是不可接受的。
伺服器資源消耗：Blazor Server 的工作原理是將整個應用部署在伺服器上，每個使用者都會佔用一個連接和一些伺服器資源。對於線上工具或遊戲等需要大量使用者同時線上的應用來說，這可能會導致伺服器資源消耗過大，難以擴展和維護。
客戶端效能限制：Blazor Server 的 UI 渲染是在伺服器上完成的，然後透過 SignalR 將更新的 UI 推送到客戶端。這意味著客戶端的效能對於應用的回應速度和使用者體驗有很大影響。對於一些複雜的線上工具或遊戲來說，客戶端的效能可能無法滿足需求。
綜上所述，Blazor Server 更適合開發那些對即時性要求不高、使用者量較小、對伺服器資源消耗要求不高的網站應用。對於線上工具或遊戲等需要即時性和大量使用者同時線上的應用，Blazor WebAssembly 可能更適合，因為它可以將整個應用部署到客戶端，減輕了伺服器的負擔，並提供了更好的使用者體驗。
4. 選擇Blazor Wasm開發工具站理由
Dotnet9 網站選擇Blazor Server依然不變，因為部落格類網站需要SEO，需要搜尋引擎提供流量。
而 Dotnet工具箱 主要關注的是線上小工具和小遊戲，所以選擇Blazor Wasm，當談到選擇Blazor WebAssembly時，有幾個令人興奮的優勢值得一提：
即時效能：Blazor WebAssembly利用WebAssembly（Wasm）技術，將C#程式碼編譯成高效能的二進位格式，可以在瀏覽器中直接執行。這意味著您可以在客戶端使用C#編寫的應用程式，而無需將其轉換為JavaScript。這種直接執行的能力使得Blazor WebAssembly具有接近原生應用程式的效能，為使用者提供更快的載入速度和更流暢的使用者體驗。
跨平台：Blazor WebAssembly是一個跨平台的解決方案，可以在各種作業系統和裝置上執行，包括Windows、Mac、Linux和行動裝置。這意味著您可以使用相同的程式碼庫構建適用於不同平台的應用程式，從而減少開發和維護的工作量。
開發效率：Blazor WebAssembly使用C#語言和.NET框架，這是一個廣泛使用的開發工具和生態系統。如果您已經熟悉C#和.NET，那麼您可以立即開始使用Blazor WebAssembly進行開發，無需學習新的語言或框架。這種開發效率可以大大加快專案的開發速度，並減少開發人員的學習曲線。
強大的生態系統：Blazor WebAssembly是基於.NET生態系統構建的，這意味著您可以利用.NET的豐富功能和第三方庫來構建功能強大的應用程式。您可以使用.NET的各種工具和技術，如Entity Framework、ASP.NET Core等，來簡化開發過程並提高應用程式的質量和可維護性。
安全性：Blazor WebAssembly應用程式在客戶端執行，但它們是在沙箱環境中執行的，與原生應用程式相比，它們具有更高的安全性。這意味著您可以在客戶端執行敏感操作，而無需擔心安全問題。此外，由於使用C#編寫程式碼，您可以利用.NET的安全功能來保護應用程式免受常見的安全漏洞和攻擊。
綜上所述，Blazor WebAssembly具有即時效能、跨平台、開發效率、強大的生態系統和安全性等令人興奮的優勢。這些優勢使得Blazor WebAssembly成為一種令人激動的技術選擇，為開發人員提供了構建高效能、跨平台的Web應用程式的新方式。
重點：WASM才是Blazor的未來。
5. 詳細對比Blazor Server和Blazor Wasm
Dotnet9 網站選擇Blazor Server，可在線上工具和線上遊戲頁面體驗Server，比如 掃雷遊戲，在遊戲頁面也可選擇跳轉到 Dotnet工具箱 的 掃雷遊戲 頁面，這是Wasm版本，可透過瀏覽器F12打開開發者工具查看網路請求情況，下面簡單說說查看步驟。
Dotnet9 頁面的 掃雷遊戲，點擊工具欄可以跳轉到 Dotnet工具箱 的 掃雷遊戲 頁面：
Dotnet9 頁面的 掃雷遊戲頁面，看網路請求，幾乎一直在請求，簡直令人髮指，喪心病狂：
Dotnet工具箱 的 掃雷遊戲 頁面，看網路請求，只有網頁的圖片請求，其他請求就沒有，這就是客戶端的魅力（WebAssembly）：
關於Blazor，或Blazor Server與Blazor Wasm，相信很多人只是聽說過，對相關的概念了解不多，這裡透過詢問GPT，回答的和前面段落類似，這裡再對比列出給大家做個普及吧：
Blazor是一個用於構建Web應用程式的開源框架，它允許使用C#和.NET來編寫客戶端程式碼。Blazor有兩種模式：Blazor Server和Blazor WebAssembly（Wasm）。下面是對這兩種模式的詳細對比：
- 架構：
- Blazor Server：Blazor Server模式將應用程式的UI渲染在伺服器上，然後透過SignalR將UI更新推送到客戶端。客戶端透過與伺服器建立持久連線來接收UI更新和處理使用者互動。
- Blazor WebAssembly：Blazor Wasm模式將整個應用程式的程式碼和依賴項編譯為WebAssembly格式，並在客戶端上執行。應用程式在客戶端上獨立執行，不需要與伺服器保持持久連線。
- 效能：
- Blazor Server：Blazor Server模式的效能受到伺服器和網路的影響。由於UI渲染在伺服器上進行，因此對於大型應用程式或高並發場景，可能會對伺服器造成較大的負載。
- Blazor WebAssembly：Blazor Wasm模式的效能主要受到客戶端裝置的影響。由於應用程式在客戶端上執行，因此可以獲得更好的回應速度和更低的延遲。
- 可靠性：
- Blazor Server：Blazor Server模式依賴於伺服器的穩定性和可用性。如果伺服器出現故障或網路連接中斷，應用程式將無法正常運作。
- Blazor WebAssembly：Blazor Wasm模式在客戶端上獨立執行，不依賴於伺服器的穩定性和可用性。即使伺服器不可用，應用程式仍然可以繼續執行。
- 開發體驗：
- Blazor Server：Blazor Server模式的開發體驗類似於傳統的伺服器端開發，可以使用.NET的完整功能和生態系統。但是，由於UI渲染在伺服器上，因此在處理使用者互動時需要考慮與伺服器的通訊延遲。
- Blazor WebAssembly：Blazor Wasm模式的開發體驗類似於客戶端開發，可以使用C#和.NET的大部分功能，但某些功能可能受到限制。由於應用程式在客戶端上執行，因此可以提供更接近原生應用程式的使用者體驗。
總的來說，Blazor Server適用於需要快速開發和部署的應用程式，而Blazor WebAssembly適用於需要更好的效能和獨立執行的應用程式。選擇哪種模式取決於應用程式的需求和優先級。
6. 最後的話
前面兩篇文章，有部分網友建議站長使用Wasm模式，站長已經成功部署上線了，大家有什麼工具需求歡迎留言，站長有空會考慮加上，當然希望大家能PR工具和遊戲，只限於Blazor WASM開發的哦。
今天分享到這，十分感謝您的閱讀。
- 網站位址：https://dotnetools.com/
- 網站原始碼：https://github.com/dotnet9/Dotnet9
- .NET版本： .NET 8.0.0-preview.5.23280.8
- 微信技術群：新增站長微信（codewf），一定要備註【入群】2個字
- QQ技術群：771992300