搞了個Blazor工具站，功能變數名稱一次性買了10年！

大家好，我是沙漠盡頭的狼。

在 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 不適合開發線上工具或游戲之類的網站應用，主要是因為它的工作原理和特性導致了一些限制和不適用的情況。

1. 實時性限制：Blazor Server 使用了 SignalR 技術來實現與伺服器的實時通信，但由於所有的 UI 更新都需要通過伺服器來完成，因此在網路延遲較高的情況下，用戶可能會感受到明顯的延遲。這對於線上工具或游戲等需要實時響應的應用來說是不可接受的。

2. 伺服器資源消耗：Blazor Server 的工作原理是將整個應用部署在伺服器上，每個用戶都會占用一個連接和一些伺服器資源。對於線上工具或游戲等需要大量用戶同時線上的應用來說，這可能會導致伺服器資源消耗過大，難以擴展和維護。

3. 客戶端性能限制：Blazor Server 的 UI 渲染是在伺服器上完成的，然後通過 SignalR 將更新的 UI 推送到客戶端。這意味著客戶端的性能對於應用的響應速度和用戶體驗有很大影響。對於一些複雜的線上工具或游戲來說，客戶端的性能可能無法滿足需求。

綜上所述，Blazor Server 更適合開發那些對實時性要求不高、用戶量較小、對伺服器資源消耗要求不高的網站應用。對於線上工具或游戲等需要實時性和大量用戶同時線上的應用，Blazor WebAssembly 可能更適合，因為它可以將整個應用部署到客戶端，減輕了伺服器的負擔，並提供了更好的用戶體驗。

4. 選擇Blazor Wasm開發工具站理由

Dotnet9 網站選擇Blazor Server依然不變，因為博客類網站需要SEO，需要搜索引擎提供流量。

而 Dotnet工具箱 主要關註的是線上小工具和小游戲，所以選擇Blazor Wasm，當談到選擇Blazor WebAssembly時，有幾個令人興奮的優勢值得一提：

1. 即時性能：Blazor WebAssembly利用WebAssembly（Wasm）技術，將C#代碼編譯成高效的二進位格式，可以在瀏覽器中直接運行。這意味著您可以在客戶端使用C#編寫的應用程式，而無需將其轉換為JavaScript。這種直接運行的能力使得Blazor WebAssembly具有接近原生應用程式的性能，為用戶提供更快的載入速度和更流暢的用戶體驗。

2. 跨平臺：Blazor WebAssembly是一個跨平臺的解決方案，可以在各種操作系統和設備上運行，包括Windows、Mac、Linux和移動設備。這意味著您可以使用相同的代碼庫構建適用於不同平臺的應用程式，從而減少開發和維護的工作量。

3. 開發效率：Blazor WebAssembly使用C#語言和.NET框架，這是一個廣泛使用的開發工具和生態系統。如果您已經熟悉C#和.NET，那麼您可以立即開始使用Blazor WebAssembly進行開發，無需學習新的語言或框架。這種開發效率可以大大加快項目的開發速度，並減少開發人員的學習曲線。

4. 強大的生態系統：Blazor WebAssembly是基於.NET生態系統構建的，這意味著您可以利用.NET的豐富功能和第三方庫來構建功能強大的應用程式。您可以使用.NET的各種工具和技術，如Entity Framework、ASP.NET Core等，來簡化開發過程並提高應用程式的質量和可維護性。

5. 安全性：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）。下麵是對這兩種模式的詳細對比：

1. 架構：

• Blazor Server：Blazor Server模式將應用程式的UI渲染在伺服器上，然後通過SignalR將UI更新推送到客戶端。客戶端通過與伺服器建立持久連接來接收UI更新和處理用戶交互。
• Blazor WebAssembly：Blazor Wasm模式將整個應用程式的代碼和依賴項編譯為WebAssembly格式，併在客戶端上運行。應用程式在客戶端上獨立運行，不需要與伺服器保持持久連接。

2. 性能：

• Blazor Server：Blazor Server模式的性能受到伺服器和網路的影響。由於UI渲染在伺服器上進行，因此對於大型應用程式或高併發場景，可能會對伺服器造成較大的負載。
• Blazor WebAssembly：Blazor Wasm模式的性能主要受到客戶端設備的影響。由於應用程式在客戶端上運行，因此可以獲得更好的響應速度和更低的延遲。

3. 可靠性：

• Blazor Server：Blazor Server模式依賴於伺服器的穩定性和可用性。如果伺服器出現故障或網路連接中斷，應用程式將無法正常工作。
• Blazor WebAssembly：Blazor Wasm模式在客戶端上獨立運行，不依賴於伺服器的穩定性和可用性。即使伺服器不可用，應用程式仍然可以繼續運行。

4. 開發體驗：

• 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/dotnetools
• .NET版本： .NET 8.0.0-preview.5.23280.8
• 微信技術群：添加站長微信（dotnet9com），一定要備註【入群】2個字
• QQ技術群：771992300