.NET和WebAssembly——這會是前端的未來嗎?
譯者注：作者在本文詳細介紹了.NET是如何與WebAssembly進行結合的，描繪了一幅前端世界美好的藍圖。以下為譯文。
6年前，Erik Meijer和我談論了JavaScript是如何成為一種組合語言的。最終這個話題變成了一個有趣的討論/爭論(有些人不這麼覺得)，但是辯論還是在繼續發生著。目前，WebAssembly正在向前發展，已經可以支援Chrome、Firefox了，而且還支援在Edge、Opera和Safari中進行開發。
上面的圖片來自於Steve Sanderson的NDC演示。他正在開發的應用就屬於典型的客戶端JavaScript ToDo應用，只有一點比較例外，就是他是用C#寫的程式碼。
WebAssembly是什麼？
“webassmbly或wasm是一種低階的位元組碼格式，用於瀏覽器的客戶端指令碼，由JavaScript演變而來。”現在你可以很容易地從C和C++編譯成WebAssmbly。每天都有更多的語言把WebAssmbly包含進來作為目標。
因為我在開源.NET裡面工作，而且即將釋出的.NET Core 2.0是支援跨平臺的，所以我認為很值得探索WebAssmbly與.NET是在哪裡開始融合的。
以下是一些我認為有助於在.NET和WebAssembly之間架起橋樑的專案。我認為在接下來的18個月時間裡這些都會是熱門領域。
忽略它的名字，這個OSS專案的目的是為了消耗WASM二進位制檔案，並從.NET程式集中執行它們
有趣的是，這個專案並沒有啟動V8或Chakra JavaScript引擎來執行WASM，相反，而是用位元組碼對它進行讀取，然後通過System.Reflection.Emit把它們給轉換成.NET。
.NET生態系統裡面發生了一件很偉大的事情，就是現在已經有不止一個”.NET”了。過去.NET是隻安裝在Windows上的，這一點很多人都挺擔心的。現在基本上每臺Windows機器上面都會安裝.NET 4.x+，而且還有了可以在Docker，在Mac、Windows和Linux平臺上執行的.NET Core。即使是Raspberry Pi，現在也有了Mono，它是.NET的另外一種例項，可以在多個平臺上面執行程式碼。
第一個使用的是Mono的傳統的全靜態編譯模式，它既編譯了Mono C執行時和Mono類庫以及使用者程式碼到webassmbly程式碼。它生成一個大型靜態編譯的應用程式。您可以在這裡嘗試這個完全靜態編譯的Hello World。完整的靜態編譯現在在這裡。
這是一個全靜態編譯的Hello World。它是所有的Mono和你的應用程式。他們有另一個原型，有不同的觀點:
第二個原型將Mono C執行時編譯成web彙編，然後使用Mono的IL直譯器來執行託管程式碼。雖然很小，但效能消耗很大。混合模式的執行原型現在在這裡。
他們就是用這種方式在Web彙編中有很多的Mono，但是IL程式碼是解釋的。電腦科學的一個奇妙之處是，有不止一種方法可以做一些事情，而且它們通常都以各自的方式令人敬畏。
[“BLAZOR” - 基於瀏覽器執行.NET的實驗性UI框架)
與Mono專案的第二個原型類似，Steve Sanderson又採取了另一個“.NET的例項”，已經6年的開源DotNetAnywhere(DNA)專案，並將其編譯成Web Assembly。DNA是一種用portable C編寫的解釋性的.NET執行時，它採用標準的IL或CIL(通用的中間語言)，在那些“不可能完整執行.NET執行時(例如Mono)的資源受限的裝置上”執行。很聰明是嗎?“6年後我們還有什麼資源受限的裝置?”為什麼，因為這些裝置只可能是小型虛擬機器——你的瀏覽器已經擁有了JavaScript VM，現在是由一個稱之為WebAssembly的標準位元組碼格式驅動。
為了證明這一概念，Steve將DotNetAnywhere編譯為WASM，但隨後又將其進一步推進。他將那些我們在web上看到的標準程式設計模型和比如Angular、KnockoutjsEmber給結合在一起了，而不是用JavaScript編寫web應用程式的UI，而是用ca-a編寫。網路語言。
在一些Razor的中間(基本上是帶有C#內聯的HTML)頁面，他做的是對後端的呼叫。這是C#程式碼，但它將在一個Blazor應用程式的客戶端上執行。
這將允許a。NET程式設計師可以在客戶端和伺服器上使用相同的資料模型——就像今天應該使用的JavaScript程式碼一樣——也可以使用其他的資料模型。他們可能熟悉或熟悉的網路庫。
其它可能性?
在這一點上很明顯，每個人都在進行原型設計和黑客活動，並享受著自己的樂趣。
你對WebAssembly有什麼看法?
網友精彩評論
MIKE-EEE：這裡忽略的是成本的商業問題。微軟在這一點上令人感到吃驚，雖然它是一家商業公司，但在卻繼續在提供昂貴的解決方案。當你將JavaScript與.NET專案結合時，實際上你是將開發人員必須編寫和維護的程式碼量增加了一倍。值得注意的是，這是多年來的主流指導，而不是以某種方式提供支援.NET(由JSIL的一些非官方和人員不足的能力證明)。
一旦程式碼被封裝起來，它的價值主張就是利用知識，在沒有比這更大的例子中可以看到。2.0網路標準。基於javascript的應用程式根本不參與這種動態，因此在與.NET一起使用時，會增加時間和資源的額外成本。
這就是讓Mono命題如此激動人心的原因，因為它會參與.NET標準2.0，並提供這樣的配對所帶來的成本節省。這就像回到過去的6年，再一次在Silverlight裡工作，這是基於這樣一個範例。只有這一次，我們將在現代使用者體驗時代擁有6年的經驗，以改進其原有的願景，並以更大膽、更好的形象打造出更大膽、更美好的東西.NET和microsoft。
Theo Albers：這種方法的一個危險是，在顯示web頁面之前我們必須等待下載先完成才可以。難道我們正在回到外掛時代嗎?在準備頁面時，沒有人喜歡cookie wall或繁忙的指示器。
web瀏覽器支援清晰地分離關注點(樣式、結構、內容和行為)，這提供了很大的靈活性。然而，我們很難在網站上有效地管理這種靈活性。這就是為什麼我認為網路模型被打破了。
**Jesper：**WASM很棒，讓C#的邏輯在其它後臺執行，而不是CLR，但是我希望微軟不要再嘗試ActiveX或Silverlight了，這意味著嘗試在上面執行你自己的UI堆疊，並“抽象”HTML、DOM和CSS。雖然Silverlight從一開始就註定要失敗,因為行業的標題,這並沒有阻止它從一個巨大的開發者努力同時焦油坑和那些不幸賭了兩次——一次投資relitigate所有UI問題,再次離開。
我們這些做真正工作的人仍然需要把網路的其他部分當作平臺來對待——在網路上，適應大量新標準、技術和裝置的不斷增加，這意味著你需要成為網路的一部分。無論你用什麼樣的方式解決問題，都應該與其他瀏覽器環境和周圍的技術相吻合，否則這個東西就會死在水裡。
Cristian Merighi：在我看來，微軟是想要跳過日益增長的WebComponents時代，想直接進入到他們的時代。
聽起來很合理，好像根本不是在抱怨(你必須進行研發和試驗)，但是首先要給優秀的開發者一個堅實的主流平臺，這是非常感謝的。
(儘管這樣我還是會試試)
Andrew：我很驚訝沒有人提到過Wisej.com框架。他們設計了一款非常好的產品，在設計網頁app時，它已經去掉了很多複雜的步驟。我從事的工作主要是用SQL去開發winforms業務應用程式，因此我幾乎接觸不到Wisej產品。
當安排我設計一個web應用程式時，我發現了這款產品，並查看了所有需要了解的web層，就像asp.net，html，java，jquery，typescript，angular，bootstrap等等那樣，我認為肯定會有一個更簡單的方法，結果的確是有！可以用C#或者VB.net進行開發，你可以像構建winforms應用一樣去構建應用，所有這些都可以使用標準的類在VS中實現完整的智慧感知。釋出後的應用程式會基於瀏覽器進行執行。我現在已經有了一個完整的資料繫結業務產品，它可以在移動端和桌面作業系統上執行，將於下個月推出。它大概花了3個月的時間，我也不需要在調整什麼了。這款產品不是免費的，但價格遠低於1000美元。
如果你現在沒有什麼思路，或者需要開始一個新的專案，那絕對值得一看。