Javascript交叉編譯方案很多了，工業級品質的也不是沒有，但前兩年我從事html5 3d引擎開發時，做過一圈評估，沒有可用的。
作為一個c#愛好者，我自然是很希望能最大限度的利用c#的生產力，之前經過評估，我們選擇了typescript 作為開發工具，確實也產生了一些收效。
時過境遷，雖然很久不做h5方面的開發，但任然關注，偶然發現bridge.net的發展速度相當的不錯，今日觀之，社群已經相當成熟。就手癢，又評估了一把。
先上原始碼
https://github.com/lightszero/bridge.net.study
也直接有生成的頁面
https://lightszero.github.io/bridge.net.study/webapp/webapp/index.html
先說結論
Bridge.net成熟度很高，我嘗試了一些c#的語法，都可以正常工作。
也發現了一些小小的問題，懂一些js一對比很容易解決。
會帶入一個bridge.js 1M多，壓縮版800k
Bridge採取的方案是直接將c#程式碼編譯為js，準確的說是IL程式碼。而且採用的方法比較暴力，對無法直接對應的一些c#常用功能，直接寫了一套js底層類庫來支撐。
這就是那1M的來歷，好處是編譯過程就會相對比較簡單，越簡單的機制越容易穩定。
對比typescript方案主要有3個優點
1. 有整數，在語法表達方面會更清晰
2. 有struct，這個我就不多言戰術價值了
3. C#，這就仁者見仁了
主要有兩個缺點
1. 多了1M的依賴庫
2. 生成的程式碼多了一層包裝，沒有typescript生成的程式碼乾淨。
老有人拿untiy的webgl方案說事，我只說一條。
Unity的webgl方案是構築在webassembly基礎上的，微信小遊戲不支援。
現在來說說bridge.net 怎麼用
0. 首先你得是個Visual studio 使用者，不是當我沒說
1. 根本不用安裝，因為他的原理就是一個c#dll 和 編譯相關的dll，只需要dll和csproj的相關配置，這個工作nuget就可以完成。
你隨便建立一個c#專案，然後nuget 安裝 bridge.net 就行了
我是用一個asp.net專案做模板，然後nuget安裝bridge.net,因為asp.net 專案 按F5 就可以直接啟動頁面呀，就這麼簡單。
2. 然後只要build專案的時候bridge.net就會自動給你生成js了，他會使用bridge.js來做一些配置選項
3. 關於功能
前面安裝的briage.net 只是安裝環境，首先要使用html5自己的介面，就是訪問 window 呀這些，需要再nuget安裝 bridge.html5.
我要開發個webgl介面來試試，就nuget安裝bridge.webgl
4. 關於除錯
瀏覽器除錯，略。
因為html 有map檔案標準，所以你瀏覽器除錯也是可以看到c#的，而且可以下斷電，觀測值
你要確認的事情就是bridge.json開啟了map的輸出
不過bridge.net有一點不好，他提供的功能，對命名做了修改
就比如這個GetContext，在js裡是getContext
因為這個修改，對除錯造成了一些小小的麻煩，瀏覽器除錯工具是針對js的，還要用原來的名字才能找到。因為瀏覽器的map檔案只有js和原始檔行數的對映，沒有變數名函式名這些。
但問題不大，我們知道它主要就改了大小寫而已，除錯的時候多敲一下的問題
那麼可不可以直接在vs裡面下斷點除錯呢，也是可以的。因為bridge輸出的map檔案用的相對路徑，只要把bridge.json的輸出路徑改一下，就行
然後開啟vs的指令碼除錯功能
注意vs2017才有google chrome的除錯功能（印象中），vs2015只能除錯ie去
然後就可以直接在vs裡面斷點了，需注意因為他做了一個改名的動作，除錯的時候對監視器產生了影響