Web開發與JavaScript開發向來是同義詞。直到WebAssembly的橫空出世，WebAssembly (Wasm)是一種在瀏覽器中可以執行的二進位制指令。 WebAssembly 的 官方工具鏈 能夠編譯 C/C++ 程式碼，但許多社群也提供了不同語言的編譯器，如 Rust，Python，Java 和 Blazor(C#)。特別是 Rust 社群非常活躍，可以開始看到完整的前端框架，如 Yew 和 Dodrio，這為基於瀏覽器的應用帶來了更多新的可能性，只要測試一些使用 WebAssembly 構建的優秀應用，就可知道基於瀏覽器的近乎原生的應用現在已經成為現實，例如 Sketchup 或 Magnum。

WebAssembly被設計為可以和JavaScript一起協同工作——通過使用WebAssembly的JavaScript API，你可以把WebAssembly模組載入到一個JavaScript應用中並且在兩者之間共享功能。這允許你在同一個應用中利用WebAssembly的效能和威力以及JavaScript的表達力和靈活性，即使你可能並不知道如何編寫WebAssembly程式碼。

2017年 微軟開始嘗試基於WebAssembly使用Mono執行時讓.NET進入瀏覽器，Mono為.NET執行庫(.dll)提供了基於WebAssembly執行的環境。執行在Mono之上的是Blazor，一個構建於.NET的單頁Web應用開發框架，通過Mono的WebAssembly執行時在瀏覽器中執行。 經過了3年時間的開發，2020年5月19日在微軟年度技術大會Build上正式釋出，我們來看一看Blazor將如何改變Web開發。

Blazor是什麼？

Blazor 允許您使用 C# 而不是 JavaScript 構建互動式 Web UI。

• Blazor 應用由使用 C#、HTML 和 CSS 實現的可重用 Web UI 元件組成。
• 客戶端和伺服器程式碼都用 C# 編寫，允許您共享程式碼和庫。

在很長一段時間內，我們構建了僅在伺服器上執行的應用程式，使用ASP.NET、PHP 等技術，在服務端生成了要推送到瀏覽器的 HTML 檔案。我們始終與 JavaScript 和 AJAX 有一些互動性，但多年來，大多數業務邏輯都處理在伺服器本身上，吐出 HTML 頁面進行互動，瀏覽器只是一個文件檢視器。

瀏覽器裡很多年也是IE 當道，直到Chrome 這個瀏覽器的出現，IE 11之後微軟重新用Chrome的心臟置換了Microsoft Edge，慢慢的改變了我們前端開發的模式，進入了單頁面應用程式時代，這個時代的典型代表就是Angular，React和Vue。我們在瀏覽器裡執行JavaScript構建的完整應用程式，見過大量的.NET程式設計師轉戰前端戰場。 我們拆分業務邏輯，做到前後端分離架構，以便某些邏輯在瀏覽器上執行，有些在伺服器上執行。JavaScript 應用程式執行客戶端並使用訊息傳遞與"伺服器"通訊。您可以輕鬆地將"伺服器"替換為雲中的服務或應用程式，但模型仍然相同。

Blazor 藉助於WebAssembly技術 改進這種前後端分離的模式，他有兩種模式支援：Blazor WebAssembly 應用和Blazor Server ，個人認為Blazor Webassembly 模式的應用才是這種前後端分離的正途：

瀏覽器充當應用程式的宿主。在 Blazor WebAssembly 應用程式中構建的檔案將編譯併發送到瀏覽器。然後，瀏覽器在瀏覽器的執行沙盒中執行您的 JavaScript、HTML 和 C#。它甚至執行 .NET 執行時的版本，這個執行時處理 JavaScript 互操作，並提供基本服務（如垃圾回收）和更高級別的功能（佈局、路由和使用者介面小部件等）。換句話說，blazor使用了一個駐留在另一個虛擬機器中的虛擬機器，堪稱《盜夢空間》級別的悖論，也是一種在瀏覽器中執行非 JavaScript 應用程式框架的巧妙方法。這意味著您可以在瀏覽器中執行對 .NET 的呼叫，並且它是瀏覽器中成熟的應用程式。它甚至可以離線執行。

執行時使得blazor 和 WebAssembly 上執行的其他語言與眾不同，MonoCLR 編譯為WebAssembly。任何.NET Standard 2.1的程式碼都可以在上面執行，這樣就可以把.NET生態的大量庫帶到前端開發，其他的語言只實現了直接編譯為WebAssembly，blazor當前利用WebAssembly 的一個獨特創新。

為什麼這是很酷的：

• 您可以在任何靜態檔案伺服器上執行它（Nginx、ISS、Apache、S3、Heroku 等）
• 它以WebAssembly 執行 JS，以接近本機的速度執行 C#。
• 您可以使用 C# 開發豐富的前端應用程式。
• 後端的API服務可以是任何語言，比如Java，PHP，Python，go
• 重用 .NET 元件
• 使用 Microsoft 工具（Visual Studio和Visual Studio Code）和除錯

這非常適合低延遲應用程式，如遊戲。如果您不需要與伺服器通訊，則無需與伺服器通訊。您可以下載應用程式並在瀏覽器中離線執行該應用程式。

一些缺點：

• 首次需要下載 .NET 框架和其他執行時檔案（一次）
• 您僅限於瀏覽器的功能
• 在本地下載的所有機密（憑據、API 金鑰等）
• 並非相容所有 .NET 框架元件

有這些缺點也正是Blazor Server應用程式模型可以彌補，可以擁有要.NET的全部功能和瘦客戶端。

.NET切入Web開發的一個特殊優勢，就是有了可以替換npm和WebPack的工具。 作為一個多年的.NET程式設計師，我可以向NuGet（包管理程式）和MSBuild招手了。對我而言，這些工具問題少，更熟悉，且效率也高得多。儘管沒有完美的事物，但我使用NuGet和MSBuild的體驗一直是很好的。這裡不要誤解我的意思，不是npm和Webpack不好，希望大家放棄它們，但反之也一樣。npm和WebPack都是偉大的工具，還會存在相當長的時間。如果你的JavaScript工具用來建立Web應用很好使，那沒問題。基於我對Web開發多年的認知，我明白為什麼會出現npm和WebPack，也對它們取得的成熟和將要做出的貢獻表示讚賞，微軟也是花了大價錢把npm的提供商收至麾下，微軟肯定不是傻子。 

Blazor讓我非常震撼的是它使用起來非常簡單。公平地說，我承認Blazor的生態還不夠完善，大量的利用前端技術圈的成果的開源專案正在不斷湧現。Blazor把簡單易用的Razor（UI）與其他.NET核心概念組合起來：依賴注入、配置、路由。而且從Angular及React等流行JavaScript框架借用了最佳模式，同時利用了Razor模板，並提供了與其他.NET慣例的一致性。這些功能的組合支援前所未有的技能重用。

使用WebAssembly並不意味著可以拋棄JavaScript。 WebAssembly眼下還只能被JavaScript載入和編譯。（沒錯，這有點亂。）雖然未來的計劃讓WebAssembly模組可以像ES6模組一樣被瀏覽器載入，但JavaScript還是啟動WebAssembly必需的。JavaScript的必要性還不止於此。WebAssembly自身無法訪問任何平臺API，而要訪問這些API，JavaScript也是必要的。開發者可以通過Blazor interop在 WebAssembly自身不足時把JavaScript作為後備，此外這個互動機制也是一個抽象層，很多使用C#的程式設計師都會用到，他們不必擔心底層執行的還是JavaScript。

是不是使用C#開發Web 讓你激動， WebAssembly及ASP.NET Core的Blazor等框架就值得投入一些時間了呢？至少我學了那麼多年.NET，現在終於可以用它來更快地做Web開發了，還是很值得炫耀的，這也是我有動力寫這篇文章的原因。不僅如此，我其實也很熟悉JavaScript，而且還在不斷學習。作為一個工程師，擁有這些技能就有了解決問題的思路。