0

私は現在、多数のWebサイトに含まれている大規模なJavascriptコードベース(現在約15万個の縮小版)を使用しています。機能が追加されるにつれてサイズが大きくなっているので、現在、サイズを縮小する方法を調査しています。

現在利用可能なオプションの1つは、純粋なJavaScriptからコンパイルからJSへのライブラリへの切り替えです。クラスベースのOOPやコンパイル時の型チェックなどの機能によって作業が節約されるため、これは開発中に役立つ可能性があります。ただし、このような変更によって、純粋にJSで作業する場合よりもコードベースのサイズが大きくならないことが重要です。私が調査した言語はどれも、出力サイズに特に関係しているようには見えません。Dartは最も使いやすいように見えますが、コンパイルされた出力は途方もなく大きくなります。GWTは、解決するよりも多くの問題を引き起こし、出力を操作するのは特に快適ではありません。私はHaxeを自分で試したことはありませんが、同僚が試したところ、その出力は非常に肥大化していると彼は言っています。出力はかなり標準的なJavascriptであるため、CoffeeScriptはこれまでで最も有望なようです。

開発プロセスを容易にしながら、簡潔なJavaScriptを生成し、(特にGoogle Closureを使用して)適切に最小化するコンパイルからJSへの言語はありますか?それとも、手書きのJSを使い続けるほうがよいでしょうか。

手書きのJSが進むべき道である場合、出力サイズに特に大きな違いをもたらすことができるツールやテクニックはありますか?グーグルのクロージャーライブラリは、それらと私たち自身のコードとの間で機能に多くの重複があるので面白そうに見えますが、これへの切り替えには多くの作業が含まれるため、利点は重要である必要があります。

4

1 に答える 1

2

非JS言語オプションを検討している場合は、ClosureCompilerのADVANCED最適化と互換性のあるスタイルで注釈付きJSを使用することを検討する必要があります。これにより、純粋なJSライブラリを活用しながら、最小のコードサイズが得られる可能性があります。

よりワイルドなオプションについては、JSXとUberScript(タイプ拡張CoffeeScript)について良いことを聞いたことがあります。どちらも、妥当なClosureCompileスタイルのjavascriptを生成します。

ソースマップを介したソースレベルのデバッグにより、基盤となるJSソースの「かわいさ」の関連性が低くなるはずです。これら2つのプロジェクトのソースマップの状態はわかりません。Dart、GWT、およびClosureCompilerはすべてそれらを生成します。

于 2012-08-10T19:21:02.857 に答える