20

Script＃、JSIL、SharpKitをC＃をJavascriptにコンパイルするために使用するツールとして見ているので、Visual StudioでC＃を使用してAJAXのクライアント側関数をプログラムできます。

各JSIL、Script＃、SharpKitの長所と短所は何ですか？

私のプロジェクトは、必要に応じて、かみそりエンジンとC＃を使用したMVC4プロジェクトです。

4

5 に答える 5

21

MVCプロジェクトと直接統合することを検討している場合は、Script＃やSharpKitなどがおそらく最善の策です。Script＃にはそのような統合を容易にするものが組み込まれていることを知っているので、そこから始めましょう。

JSILを試してみたい場合は、おそらく必要なコア機能がありますが、Visual Studioの統合、自動展開など、必要なものはありません。現在、これは主にアプリケーションのクロスコンパイルを対象としているため、それはうまく機能しますが、他のユースケースほどうまく機能しません。

他の選択肢よりもJSILを検討する理由の概要を説明します。これらの選択肢を使用したことがないため、これらの選択肢の長所と短所について詳しくコメントすることはできません。

JSILは、C＃4で利用可能な機能を非常に幅広くサポートしています。注目すべき機能（他のツールがそれらをサポートしていないか、複雑であるため）には次のものがあります。

dynamic、 yield、 Structs、 ref / out、 Delegates、 Generics、 Nullables、 Interfaces、およびEnums。

もちろん、上記のいくつかは完全なサポートを持っていません-絶対に機能するもののアイデアを得るために、テストケースを見ることができます-それぞれは、確認するためにテストされる小さな自己完結型の.csファイルですJSILとネイティブC＃は同じ出力を生成します。

この広範なサポートの理由は、JSILが、完全に変更されていないC＃アプリケーションを動作中のJSに変換できるようにすることを目標としているためです。JSILサイトにあるすべてのデモについて、これは真実です。私は、これも真実である、より大きな実際のゲームのほぼ完成したポートをいくつか持っています。

もう1つの理由は、JSILを使用すると、C＃とJavaScriptが比較的簡単に会話できるようになることです。

すべてのC＃タイプとメソッドは、可能な限りJavaScriptに適したインターフェイスを介して公開されます。JSバージョンには基本的な過負荷解決とディスパッチがあるため、ほとんどの場合、ネイティブC＃インターフェイスはネイティブJSであるかのようにスクリプトコードから呼び出すことができます。JSに公開したいメソッドに具体的にタグを付けたり、特別な名前を付けたりする必要はありません。

C＃からJSに呼び出したい場合は、いくつかの方法で行うことができます。

  • JSIL.Verbatim.Expressionを使用すると、生のJavaScriptを翻訳されたバージョンの関数に直接挿入できます。
  • JSIL.Builtins.Globalをdynamicおよびvarと組み合わせて、JavaScriptのようなコードをC＃関数本体に直接書き込むことができます。
  • JSReplacement属性を使用して、C＃関数の呼び出しをパラメーター化されたJavaScript式に置き換えることができます。
  • 上記のすべての機能は、プロキシと呼ばれるタイプ情報を変更するJSILのメカニズムと組み合わせて、ソースコードがなくても、使用するライブラリのタイプ情報を変更して、メソッドをJavaScriptにマッピングできるようにすることができます。あなたが書いた。
  • そして最後に、JSに変換されないC＃メソッドは、Externalと呼ばれる空のメソッドを生成します。このメソッドは、実行時にJavaScriptに置き換えて、再び機能させることができます。置き換えていない外部メソッドは、実行時に明確な警告メッセージを生成するため、何が欠落しているかがわかります。

JSILは、提供されたメタデータとともに型情報を積極的に使用して、生成されたJavaScriptを安全に最適化しようとします。場合によっては、これにより、手動で記述した場合よりも優れた同等のJavaScriptを生成できます。現在これが当てはまる主な領域は、構造体を使用するコードですが、他の場合にも適用できます。

たとえば、このコードスニペットでは、JSILは、コードによって暗示される構造体コピーの数にかかわらず、コードが正しく動作するために実際にはどのコピーも必要ないことを静的に判断できます。結果として得られるJavaScriptには不要なコピーがないため、元のC＃のセマンティクスを単純に変換した場合よりもはるかに高速に実行されます。これは、単純な構造体ベースのもの（どこでもVector2s！）を書くことと、名前付きの戻り値の最適化を手作業で完全に理解することの間の良い中間点です。これは、過去に説明したように、かなりエラーが発生しやすいです。

さて、今、いくつかの欠点があります。このリストを網羅的とは見なさないでください。

  • .NET BCLの大部分には、JSILによって提供される実装がありません。将来的には、Mono mscorlib全体をJavaScriptに変換することでこれに対処できる可能性がありますが、当面の解決策として提唱するほどうまく機能していません。（これまでのところ、ゲームではBCLをあまり使用しないため、これで問題ありません。）この問題は、主にMicrosoftのmscorlibの翻訳に関連するIPの問題が原因です。合法的にそれを行うことができれば、正しく行うことができます。今-私が最後にテストしたときに動作しました。
  • 上記のように、VisualStudioの統合はありません。JSILは非常に使いやすく、.slnファイルをフィードして一連の.js出力を自動的に取得し、プロジェクトの横にある構成ファイルを使用して自動的に構成できますが、スクリプトのように洗練されたものや統合されたものにはほど遠いです。 ＃。
  • ベンダーやサポートスタッフはいません。昨日バグを修正したい場合、または問題が発生している場合は、現時点で私が唯一の賭けです（ただし、状況を改善するのに役立つ多くの貢献者がいますが、もっと多くの人がいつでも歓迎します！）
  • JavaScriptのパフォーマンスは、目に見えない地雷でいっぱいのひどい迷路です。アプリを動作させたいだけなら、おそらくここでは問題はありませんが、私のように実際のゲームをブラウザで高速に実行しようとしている場合、JavaScriptはあなたの人生を地獄にし、場合によってはJSILはそれを悪化させます。私がここで言える唯一の良いことは、私がそれに取り組んでいるということです。:)
  • JavaScriptのミニファイアとClosureのようなオプティマイザーは、コードジェネレーターが一連のフープをジャンプする必要があるため、明示的にサポートされていません。コードの使用方法によっては、これが実際のブロッカーであることがわかりました。
  • 静的アナライザーはまだ脆弱であり、言語サポートにはまだギャップがあります。私がJSILを使用して移植する各大きなアプリケーションは、通常、JSILの1つまたは2つのバグを明らかにします。巨大なゲームブレーカーではありませんが、機能を確実に壊したり、動作を遅くしたりするバグです。

この情報がお役に立てば幸いです。ご関心をお寄せいただきありがとうございます。

于 2012-07-19T06:58:01.877 に答える
12

Script＃の長所：

  • 無料
  • オープンソース
  • クリーンなJavaScriptを生成します

Script＃短所：

  • C＃2.0言語のサブセットのみをサポートします
  • 別のプロジェクトでのみコンパイルでき、クライアントとサーバー間でコードを混在/再利用することはできません
  • バージョン更新の頻度が低い
  • サポートを提供していません
  • サードパーティライブラリのサポートが制限されているため、C＃APIはJavaScriptAPIとは異なります。
  • オープンソースではありません
  • JavaScriptのみでのデバッグ

SharpKitの長所：

  • 市販品
  • 完全なC＃4.0言語をサポート
  • バージョン更新の頻度が高い
  • サポートが利用可能です
  • クライアント/サーバーコードは、同じプロジェクト内で混在させて再利用できます
  • オープンソースとして維持されている広範なサードパーティライブラリのサポート-C＃APIはJavaScriptAPIと完全に一致します
  • Chromeブラウザの基本的なC＃デバッグをサポートします
  • クリーンなJavaScriptを生成します

SharpKitの短所：

  • 時間制限のない無料バージョンがありますが、小規模/オープンソースプロジェクトに限定されています
  • オープンソースではありません（ライブラリのみがオープンソースです）

JSILの長所：

  • 無料
  • オープンソース

JSILの短所：

  • C＃からではなく、IL（中間言語）から変換します。これは、コードがすでに低レベルであるため、より低い抽象化レイヤーを意味します。
  • 複雑に生成されたJavaScriptコード-ほぼILのように、読みにくく、デバッグしにくい

フィードバックへの回答：

Kevin：JSILの出力は悪くありません。これは、SharpKitのCLRモードのように、完全な.NET動作を実現するために生成されたものです。一方、SharpKitはネイティブコード生成をサポートしています。ネイティブJavaScriptコードは、手作業で記述した場合とまったく同じように、C＃から生成できます。

SharpKitのクリーンに生成されたJavaScriptコードのサンプル： http ：//sharpkit.net/Wiki/Using_SharpKit.wiki

開発者は、より複雑なコード生成を作成し、コンパイル時のメソッドのオーバーロードのサポートなど、より多くの機能を取得することを選択できます。指定すると、SharpKitはオーバーロードされたメソッドのメソッドサフィックスを生成します。

Script＃を実行するには.NET 4が必要ですが、Generics、refおよびoutパラメーター、名前空間エイリアスなどの完全なC＃4.0構文をサポートしていません。

于 2012-07-18T19:17:20.137 に答える
8

別の選択肢はWootzJsです。完全開示、私はその作者です。

WootzJsはオープンソースであり、すべての主要なC＃言語機能を可能にするかなり軽量のクロスコンパイラーになるよう努めています。

サポートされている注目すべき言語機能：

  • yieldステートメント（効率的なステートマシンとして生成）
  • async/awaitメソッド（C＃コンパイラのようなステートマシンとして生成されます）
  • refおよびoutパラメータ
  • 式ツリー
  • ラムダとデリゲート（適切なキャプチャを使用this）
  • ジェネリックスはコンパイラーとランタイムの両方でサポートされます（無効にキャストするTとキャスト例外がスローされます）
  • 閉じた変数のC＃セマンティクス（Javascriptセマンティクスとは対照的）

これはRoslynを使用して実装されます。つまり、将来の言語の改善を利用するのは、Roslyn自体を介して実装されるため、最初になります。のカスタムバージョンを提供するmscorlibため、スクリプトで実際に使用できるライブラリ機能を正確に把握できます。

その欠点は何ですか？

  • Javascriptは「きれい」に見えることを意図していません。それは明らかに機械で生成されますが、個々のメソッドはそれらを見ることで簡単に推論できるはずです。
  • コアライブラリとリフレクションを幅広くサポートしているため、生成される出力はブロック上で最小ではありません。ミニファイは最大100kのJSファイルを生成するはずですが、ミニファイはまだサポートされていません。
  • WootzJsは、C＃でのみ検出されるタイプの動作をカプセル化する関数を使用して、ネイティブタイプを恥ずかしがらずに汚染します。たとえば、のすべてのメソッドがSystem.StringネイティブJavascriptStringタイプに追加されます。
  • 現在、サードパーティのJavascriptライブラリへのバインドはほとんどサポートされていません。（現在はjQueryのみ）

他のクロスコンパイラとの比較：

  • Script＃は非常に安定しており、サードパーティのJavascriptライブラリと広範囲に統合されています。さらに、優れたVisual Studio統合があり、のカスタム実装を提供しますmscorlib。これは、ツールレベルで実際に実装されている機能を正確に把握していることを意味します。たとえば、Console.Write()実装されていない場合、そのメソッドはエディターで使用できません。

    ただし、カスタムパーサーが原因で、C＃2.0でスタックしています（そのバージョンのC＃で見つかったジェネリックもありません）。これは、現代のC＃開発者が、私たちのほとんどが予約なしで依存している膨大な言語機能のセットを放棄していることを意味します。特に、ラムダと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]ため、通常コンパイルされているクラスと区別するために、すべてのスクリプトファイルを属性で装飾する必要があります。

于 2014-02-05T15:22:55.947 に答える
5

SharpKitは2年間使用されており、コードの記述方法がアップグレードされたと言わざるを得ません。私が見ているプロ：

  • コードははるかに構造化されています。プロトタイプで「頭をぶつける」ことなく、C＃で行ったのと同じようにインフラストラクチャを開発できるようになりました。
  • リファクタリングは非常に簡単です
  • コードスニペットを使用できるため、生産性が向上し、開発時間が短縮されます
  • JSのレンダリング方法を制御できます（いくつかのモードから選択できます）。
  • ブラウザでC＃コードをデバッグできます（現在はChromeでのみサポートされていますが、引き続き：->）
  • 素晴らしいサポート！それらにクエリを送信すると、非常に高速に応答が返されます。
  • 多数のライブラリをサポートし、簡単に拡張可能

短所：

  • ドキュメントは少し貧弱ですが、一度コツをつかめば、開発を後押しします。
于 2013-02-20T07:45:02.960 に答える
2

これが役に立てば幸いです！

ScriptSharpの場合、このstackoverflowリンクが役立つ可能性があります。
ScriptSharpは私のツールキットにどのような利点をもたらすことができますか？

SVNツールをお持ちの場合は、https：//github.com/kevingadd/JSILからサンプルをダウンロードしてください。これは実用的なソースコードであり、何マイルも進むのに役立ちます。

于 2012-07-18T18:02:54.150 に答える