Webページ上のJavaScriptの静的に型付けされた代替手段は実用的でしょうか？
動的型付けと静的型付けの好みは主に好みの問題であり、さまざまな状況でさまざまな人々がそれらを多かれ少なかれ適していると感じます。
私の質問は、クライアント側のWebページの拡張などのために、JavaScriptの静的に型付けされた代替手段を技術的に持つことは可能ですか？
そのようなことが存在し得ない技術的な理由は確かにありません。 必須動的に型付けされた言語の使用は、クライアント側のコードについて特に何もありません。
他の言語が広く採用される可能性は非常に低いため、静的に型付けされたバージョンのJavaScript（つまり、Javaに近い言語）を作成し、それを通常のJavaScriptに変換するプリプロセッサを作成することをお勧めします。
たとえば、スクリプトは次のようになります。
<script type="text/staticjavascript">
String foobar(int foo, String bar) {
String result="";
for (int i=0; i<foo; i++) {
result += bar;
}
return result;
}
</script>
プリプロセッサは、すべての変数、関数、オブジェクトなどがそのタイプに従って正しく使用されていることを確認し、スクリプトを次のように変更します
<script type="text/javascript">
function foobar(foo, bar) {
var result="";
for (var i=0; i<foo; i++) {
result += bar;
}
return result;
}
</script>
すべてのブラウザが処理できます。
私の質問は、クライアント側のWebページの拡張などのために、JavaScriptの静的に型付けされた代替手段を技術的に持つことは可能ですか？
承知しました。 Google Web Toolkit は静的に型付けされたJava JavaScriptにコンパイルします...考えてみてください：Javaのすべての美しさと柔軟性、マシンのすべてのパフォーマンスを備えています-生成されたJavaScript！
真剣に、しかし、あなたはあらゆる種類の言語のためにこれをすることができて、そして多くは試みました（CとC＃のためのコンパイラも同様にありました、またはされてきました）。最終結果が実用的かどうかは、達成しようとしていることに依存します。Googleは、非常に大規模なクライアント側アプリを開発するための一貫したプラットフォームの後に、起動する独自のJavaScriptエンジンがあります。ホバー効果とその奇妙なAJAX呼び出しにこのような獣を採用すると、単に型付けされていないコードのビットで生きることを学ぶよりもはるかに多くの苦痛をもたらすことがわかります...
静的型付け言語の利点のほとんどは、コンパイル時に実現されます。言語がクライアントで解釈される場合、これらの利点の多くは失われます。それらをサーバーでコンパイルする場合、それらをロードしてクライアントで実行する方法を理解する必要があります（ActiveXコントロールを考えてみてください）。ハイブリッドアプローチ（中間のトークン化された形式にコンパイル）を使用することもできますが、基本的にはJavaアプレットに戻ります。
すでに存在しています。
ActionScript （FlashとFlexの背後にあるスクリプト言語）はECMAScriptの方言であり、強力な型を実装しており、JavaScriptとほぼ同じクライアント側の方法で使用できます（違いは、 AS3にはフラッシュプラグインが必要で、コンパイルされています）。私は最近、それを避けようとしていますが、「静的」キャンプにいる場合は、それを試してみてください。
これで主要な質問に答えることができました。これで、次の質問は「フラッシュは実用的ですか」になります。答えは「はい」で、「if」と「but」がいくつかあります
- ...何らかの理由でコードを非表示にする必要がある場合。
- ...非常に、非常に（過去のjQueryレベル）高いレベルの対話性が必要な場合
- ...しかし、HTML5がなくても、最近、ブラウザー間の互換性は大幅に向上しています。
- ...しかし、HTML5はまもなく登場します。
- ...しかし、静的なタイピング/コンパイル（解釈とは対照的）の大きな利点の1つは、最適化によって許容される追加の速度です（そして、型システムに関係なく、Flashの速度はそれほど高くありません）。
理論的には、必要なページに任意のスクリプトを貼り付けることができます。結局のところ、<script>タグにはtype属性があります。
唯一の障壁は、さまざまなブラウザーでの実装に関して十分な市場シェアを得て、使用する価値があるようにすることです。
ですから、現時点ではありそうもないことです。
それは実用的でしょうか？ 番号
出来ますか？はい！
静的に型付けされた独自のJavaScriptの代替を開発することは、せいぜい時間がかかるだけです。最悪の場合、既存のブラウザーにクライアントスクリプト言語を実装するように説得することができず、独自のブラウザーを作成する必要があります。
技術的に可能でしょうか？それをJavaで実装する場合、パフォーマンスを大幅に損なうことなく「非常に難しいが、可能」と言います。
私は実際にJavaで静的に型付けされたDSLを手書きしています。実行時の型チェックを回避するために見つけた唯一の方法は、ジェネリックスを使用して「チェックされていない」警告を抑制することです...つまり、多次元配列を実装する時が来るまで（クラスパラメータはコンパイル時に既知でなければならず、したがって本質的に有限ですが、多次元配列は無限の数の型を表します...）まだこれを理解しようとしています、残念ながら、ユーザー定義のクラスで同様の問題が発生することは間違いありません。
実は、こういう問題に出くわし続けているのですが、しばらく座ってみると良い解決策が思い浮かびます。それで、静的型付け（ランタイム型チェックなし）のperformance利点を実現するには、それは非常に困難ですが、不可能ではありません。パフォーマンスを差し引いて、一生懸命言いますが、非常に可能です。
私の経験は誰かにとって価値があるかもしれないと思っていました。
多分あなたはここであなたの答えを見つけるでしょう： https://stackoverflow.com/questions/86426/why-require-javascript-rather-than-supporting-a-standard-browser-virtual-machine
注：私の意見では、スコアが低いにもかかわらず、より最近の回答はより洞察に富んでいます。
HaXeなどの言語を使用して、静的に型指定された方法でコードを記述し、それをJavaScriptにエクスポートできます。 JavaScriptは非常に高速になりつつあるので、出力言語としては十分です。静的に型付けされた言語をWeb標準として適用しようとすることはほとんど不可能です。 JavaScriptに静的型付けを導入しようとする試み は、議論する理由から失敗しました。
技術的には、ユーザーエージェント（ブラウザ）がサポートする任意のスクリプト言語でクライアント側スクリプトを記述できます。実際には、広くサポートされている唯一の言語はJavaScript/ECMAScriptです。この段階でブラウザメーカーが新しい言語を実装してサポートするように説得しても、成功する見込みはありません。したがって、静的に型付けされた新しいクライアント側言語を使用する場合は、新しい言語をJavaScriptに変換するか、JavaScriptでその言語のインタープリターを実装する必要があります。
すでにこのようなことをしているプロジェクトがいくつかあります。たとえば、他の回答の1つで述べたように、 Google Web Toolkit です。
オプションの静的型付けはECMAScriptのProject Harmonyの一部でした-それがクライアント側の[ブラウザーベースの] JavaScriptで発生するかどうかは不明です。このウィキペディアのリンクを参照してください： http://en.wikipedia.org/wiki/ECMAScript#Future_development
現実の世界で使用されているすべてのブラウザーで新しい言語をサポートすることは望んでいません。言語はjscriptにコンパイルする必要があります。
Webのすべての例はjscriptであるため、言語はほとんどjscriptのように見えるはずです。
静的チェッカーによってチェックされているが有効なjscriptでもあるjscriptの「サブセット」を持つスコープがあると思います。例えば：
- すべての変数には、最初の使用の前に型があることを示すコメントが必要です。
- 変数のすべての使用は、上記で有効でなければなりません。
- 関数/クラスは、コメントで宣言されていない場合は使用できません＃
- Jsファイルの上部にあるコメントには、それが依存する他のすべてのjsファイルをリストする必要があります。