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里面斷點了，需注意因為他做了一個改名的動作，調試的時候對監視器產生了影響