JSIL vs Script＃vs SharpKit

Question

我正在將Script＃，JSIL和SharpKit看作是用於將C＃編譯為Javascript的工具，因此我可以在Visual Studio中使用C＃編寫AJAX的客戶端功能。

每個JSIL，Script＃和SharpKit的優點和缺點是什么？

我的項目是一個使用剃刀引擎和C＃的MVC4項目，如果重要的話。

Answer 1

如果你想直接與MVC項目集成，那么像Script＃或SharpKit之類的東西可能是你最好的選擇 - 我知道Script＃內置的東西可以使這種集成變得更容易，所以我會從那里開始。

如果您確實想嘗試使用JSIL，它可能具有您需要的核心功能，但您可能需要的東西 - 如可視化工作室集成，自動部署等 - 並不存在。 目前它主要針對應用程序的交叉編譯，因此它做得很好但不是其他用例的好工作。

我將嘗試總結一下您可能想要考慮JSIL而不是其他替代方案的原因 - 由於我沒有使用它，我無法真正評論這些替代方案的優缺點：

---

JSIL對C＃4中可用的功能提供了極大的支持。值得注意的是（因為其他工具不支持它們，或者它們很復雜）包括：

dynamic ， yield ， Structs ， ref / out ， Delegates ， Generics ， Nullables ， Interfaces和Enums 。

當然，上面的一些內容並沒有完全的支持 - 為了了解絕對可行的事情，你可以查看測試用例 - 每個都是一個小的自包含的.cs文件，經過測試以確保JSIL和本機C＃產生相同的輸出。

這種廣泛支持的原因是我的目標是使JSIL能夠將完全未修改的 C＃應用程序轉換為工作JS。 對於JSIL網站上的所有演示，這是真的，我有幾個近乎完成的大型真實游戲的端口，這也是如此。

---

另一個原因是JSIL讓你的C＃和你的JavaScript相對簡單。

所有C＃類型和方法都通過盡可能友好的javascript接口公開。 JS版本具有基本的重載解析和分派，因此本機C＃接口可以從腳本代碼中調用，就像在大多數情況下它們是本機JS一樣。 您不必采取任何步驟來專門標記您希望向JS公開的方法，或者為它們指定特殊名稱，或者除非您願意。

當你想從C＃調用JS時，可以通過以下幾種方式實現：

• JSIL.Verbatim.Expression允許您將原始javascript直接插入到函數的翻譯版本中。
• JSIL.Builtins.Global可以與dynamic和var結合使用，直接在C＃函數體中編寫類似JavaScript的代碼。
• JSReplacement屬性可用於使用參數化JavaScript表達式替換C＃函數的調用。
• 所有上述功能都可以與JSIL用於更改類型信息的機制（稱為Proxies）相結合，以允許您更改所使用的庫的類型信息，即使您沒有源代碼，也可以將其方法映射到JavaScript你寫的。
• 最后，未轉換為JS的C＃方法會生成一個名為External的空方法，然后您可以在運行時用JavaScript替換它以使其再次工作。 您尚未替換的任何外部方法都會在運行時生成明確的警告消息，以便您知道缺少什么。

---

JSIL積極使用類型信息以及您提供的元數據，嘗試並安全地優化它為您生成的JavaScript。 在某些情況下，這可以產生比手工編寫的更好的等效JavaScript - 目前這是真正的主要區域是使用結構的代碼，但它也適用於其他情況。

例如， 在此代碼段中 ，JSIL能夠靜態地確定盡管代碼隱含了結構副本的數量，但代碼中沒有一個副本實際上是正常運行所必需的。 由此產生的JavaScript最終沒有任何不必要的副本，因此它的運行速度遠遠超過了你天真地翻譯原始C＃語義的速度。 這是一個很好的中間點，在編寫基於結構的天真的東西（Vector2s無處不在！）和完全瘋狂的手工命名返回值優化 ， 正如我在過去所描述的那樣，它非常容易出錯 。

---

好的，現在有一些缺點。 不要將此列表詳盡無遺：

• .NET BCL的大部分沒有為JSIL提供的實現。 在將來，可以通過將整個Mono mscorlib轉換為JavaScript來解決這個問題，但我沒有那么好的工作來提倡它作為一個直接的解決方案。 （到目前為止，這對游戲來說很好，因為他們沒有使用大部分BCL。）這個問題主要是由於與翻譯微軟的mscorlib有關的IP問題 - 如果我能合法地做到這一點，我會做得對現在 - 它是我最后一次測試時工作的。
• 如上所述，沒有視覺工作室集成。 JSIL 是很容易使用-你可以給它一個.sln文件自動得到一堆.js文件輸出，並通過配置文件旁邊的項目自動配置它-但它遠不及拋光或集成為說，腳本＃。
• 沒有供應商或支持人員。 如果你想在昨天修復一個錯誤或者你遇到問題，我現在幾乎是你唯一的賭注（盡管有一些多產的貢獻者幫助改善事情，並且總是歡迎更多！）
• JavaScript性能是一個充滿隱形地雷的該死的迷宮。 如果你只是想讓應用程序運行，你可能不會有任何問題，但如果像我一樣你試圖在瀏覽器中快速運行真正的游戲 ， JavaScript會讓你的生活變得地獄，在某些情況下，JSIL會讓它變得更糟 。 我能說的唯一好處就是我正在努力。 :)
• 明確不支持JavaScript minifiers和優化器（如Closure），因為它們需要您的代碼生成器來跳過一堆箍。 我可以看到這是一個真正的阻止，取決於你打算如何使用你的代碼。
• 靜態分析儀仍然很脆弱，語言支持仍然存在差距。 我使用JSIL移植的每個大型應用程序通常會在JSIL中顯示一兩個錯誤 - 不是巨大的游戲破壞者，而是那些肯定會破壞功能或使得運行速度變慢的游戲。

希望這些信息有用！ 謝謝你的關注。

Answer 2

腳本#sros：

• 自由
• 開源
• 生成干凈的JavaScript

腳本#cons：

• 僅支持C＃2.0語言的子集
• 只能在單獨的項目中編譯，不能在客戶端和服務器之間混合/重用代碼
• 版本更新頻率較低
• 不提供支持
• 有限的第三方庫支持，C＃API與Jav​​aScript API不同。
• 不是開源的
• 僅在JavaScript中調試

SharpKit專業人士：

• 商業產品
• 支持完整的C＃4.0語言
• 高頻率的版本更新
• 支持是可用的
• 客戶端/服務器代碼可以在同一項目中混合和重用
• 廣泛的第三方庫支持，作為開源維護 - C＃API與Jav​​aScript API完全匹配
• 支持Chrome瀏覽器的基本C＃調試
• 生成干凈的JavaScript

SharpKit缺點：

• 有一個沒有時間限制的免費版本，但僅限於小型/開源項目
• 不是開源的（只有庫是開源的）

JSIL專業人士：

• 自由
• 開源

JSIL缺點：

• 從IL（中間語言）轉換而不是從C＃轉換，這意味着較低的抽象層，因為代碼已經是低級別的。
• 復雜生成的JavaScript代碼 - 幾乎像IL，難以閱讀和調試

反饋的答案：

Kevin：JSIL輸出並不錯 ，它只是為了實現完整的.NET行為而生成，就像SharpKit的CLR模式一樣。 另一方面，SharpKit支持本機代碼生成，其中任何本機JavaScript代碼都可以從C＃生成，就像它手工編寫的一樣。

SharpKit的簡潔生成JavaScript代碼示例： http ：//sharpkit.net/Wiki/Using_SharpKit.wiki

開發人員可以選擇創建更復雜的代碼生成並獲得更多功能，例如支持編譯時方法重載。 指定時，SharpKit為重載方法生成方法后綴。

腳本＃需要.NET 4才能運行，但它不支持完整的C＃4.0語法，如Generics，ref和out參數，名稱空間別名等...

Answer 3

另一種選擇是WootzJs 。 完全披露，我是它的作者。

WootzJs是開源的，並致力於成為一個相當輕量級的交叉編譯器，允許所有主要的C＃語言功能。

支持的顯着語言功能：

• yield語句（作為有效的狀態機生成）
• async/await方法（生成為像C＃編譯器一樣的狀態機）
• ref和out參數
• 表達樹
• lambdas和delegates（正確捕獲this ）
• 編譯器和運行時中的泛型支持（無效地轉換為T將拋出強制轉換異常）
• 封閉變量的C＃語義（與Javascript語義相對）

它是使用Roslyn實現的，這意味着它將首先利用未來的語言改進，因為這些將通過Roslyn本身實現。 它提供了mscorlib的自定義版本，因此您可以確切地知道腳本中實際可用的庫功能。

它的缺點是什么？

• Javascript並不打算“漂亮”。 它顯然是由機器生成的，盡管通過查看它們可以很容易地推斷出各個方法。
• 由於它對核心庫和反射的廣泛支持，生成的輸出不是塊中最小的。 縮小應生成~100k的JS文件，但尚不支持縮小。
• WootzJs毫不掩飾地污染了本機類型，其功能是封裝那些只能在C＃中找到的類型的行為。 例如， System.String所有方法都添加到本機Javascript String類型。
• 目前存在對第三方Javascript庫的綁定的很少支持。 （目前只有jQuery）

與其他交叉編譯器的比較：

• 腳本＃非常穩定，並且與第三方Javascript庫進行了廣泛的集成。 此外，它具有出色的Visual Studio集成，並提供mscorlib的自定義實現。 這意味着您確切地知道在工具級別實際實現了哪些功能。 例如，如果未實現Console.Write() ，則該方法將無法在編輯器中使用。

  但是，由於它的自定義解析器，它仍然停留在C＃2.0中（甚至沒有在該版本的C＃中找到的泛型）。 這意味着現代C＃開發人員放棄了我們大多數人毫無保留地依賴的大量語言功能 - 特別是除了lambda和LINQ之外的上述泛型。 這使得Script＃對許多開發人員來說基本上都不是首發。

• JSIL是一個非常令人印象深刻的工作，它將IL交叉編譯為Javascript。 它非常強大，可以輕松處理大型3D視頻游戲的交叉編譯。 缺點是，由於其完整性，生成的Javascript文件是巨大的 。 如果你只是想要mscorlib.dll和System.dll，它的下載速度約為50MB。 此外，該項目實際上並非設計用於Web應用程序的上下文，並且啟動所需的工作量有點令人生畏。

  此工具包也實現了自定義mscorlib ，再次允許您了解可用的功能。 但是，它與Visual Studio集成較差，迫使您創建調用編譯器並將輸出復制到所需位置所需的所有自定義構建步驟。

• SharpKit ：這個商業產品致力於為大多數C＃4.0語言功能提供支持。 它通常會成功，這個產品很有可能滿足您的需求。 它是輕量級的（小.JS文件），支持現代C＃語言功能（泛型，LINQ等）並且通常是可靠的。 它還為第三方Javascript圖書館提供了大量綁定。 但是，有一些令人驚訝的邊緣情況，您將不可避免地遇到這些邊緣情況。

  例如，類型系統很淺，不支持表示泛型或數組（即typeof(Foo[]) == typeof(Bar[]) ， typeof(List<string>) == typeof(List<int>) ） 。 對反射的支持是有限的，各種成員類型不能支持屬性。 表達式樹支持不存在，並且yield實現效率低（沒有狀態機）。 此外，自定義mscorlib不可用，腳本C＃文件和普通C＃文件混合在您的項目中，迫使您使用[JsType]屬性裝飾每個腳本文件，以區別於正常編譯的類。

Answer 4

我們有兩年SharpKit，我必須說我們編寫代碼的方式已經升級。 我看到他們的專業人士：

• 代碼更加結構化 - 我們現在可以開發基礎設施，就像我們在C＃中所做的那樣，沒有用原型“敲打頭腦”。
• 重構非常容易
• 我們可以使用Code Snippets，從而提高生產力並縮短開發時間
• 您可以控制JS的呈現方式（您有多種模式可供選擇）。
• 我們可以在瀏覽器中調試我們的C＃代碼（目前僅支持Chrome，但仍然： - >
• 很大的支持！ 如果您向他們發送查詢，您會非常快速地收到回復。
• 支持大量庫並且易於擴展

缺點：

• 文檔有點差，但是一旦掌握了它，你就會促進你的開發。

Answer 5

很高興，如果這可以幫助！

對於ScriptSharp，此stackoverflow鏈接可能會有所幫助。
ScriptSharp為我的工具包帶來了哪些優勢？

如果你有任何SVN工具，請從https://github.com/kevingadd/JSIL下載一個樣本，這是一個有效的源代碼，可以幫助你走幾英里。