別了，JavaScript；你好，Blazor

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、S三、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，並且還在不斷學習。做爲一個工程師，擁有這些技能就有了解決問題的思路。