Webサイトに他のクライアント側スクリプト言語がないのはなぜですか？
今日のブラウザでJavaScriptと一部のVBScriptだけがサポートされているのはなぜですか？私はJavaScriptがすべて適切であることを知っていますが、別のプログラミング言語を使用するオプションがないと、さまざまな開発スタイルを促進できませんか？
複数の言語のサポートを追加する必要はありません。解決策は、言語の実装者が使用できる汎用バイトコードで標準化することです。しかし、現時点ではこれについての計画はありません（推奨されています）。
言語はJavaScriptの上に実装することもできます。 JavaScriptは、他の言語をその上に実装できるようにするのに十分です。そして、これにはすでに多くの例があります。
JavaScriptはde-facto標準であり、1996年から使用されています。競争がないという理由だけで標準であることは厳密には公平ではありませんが、-理由別の言語が含まれていません。
別の「標準」言語を追加すると、あらゆる種類の楽しい小さな問題が促進されます。
- 他の言語でどのように機能しますか？
- DOMは共有されますか？
- 両方で書かれたスクリプトはまだ機能しますか？
- ライブラリを両方に移植する
JavaScriptだけをサポートするブラウザー間の不整合について考えてみてください。もっと言語があったらどうなるか考えてみましょう。
ブラウザは標準化する必要があります。これにより、開発したものがすべてのブラウザでどこでも機能するようになります。
複数の言語を使用している場合は、それらがすべて同じように機能することを確認する必要があります。あなたがウェブ開発者であり、言語の選択がある場合、それはいくつかの場所でサポートされているかもしれないしサポートされていないかもしれません、そしてそれは追加の頭痛です。
JavaScriptはvery柔軟な言語であり、必須であり、機能的であり、OOP（プロトタイプを使用した後））であり、解釈されます。 Chromeのようなまともなエンジンは、いくつかの良いことを合理的に行うことができます。追加の言語は、ここに設定し直し、VBScriptを見て、IEのみなので、その中に書かれているものはすべて特定のブラウザとプラットフォームに縛られ、悪夢。
これらをブラウザーに組み込む代わりに、ベンダーは不格好なブラウザープラグイン（Java、Flash、Silverlightなど）を構築することを好みます。これにより、クロスプラットフォームの一貫性が保証されます。
その理由の1つは、さまざまなブラウザーベンダーが標準のJavaScript実装に同意することさえ事実上不可能であり、少なくともWeb言語の観点からは、JavaScriptが永遠に存在し続けていることです。したがって、ほとんどの人は別のクライアント側言語をエコシステムに導入してすべてのベンダーにサポートすることは事実上不可能であり、それを実現する可能性のある人のほとんどはすでにJavaScript標準化の問題に関与していると私は考えています。彼らの時間の使用。
複数の言語をサポートすると、Webブラウザーのビルダーがすべての言語に準拠していることを確認するのが非常に厄介になると主張するいくつかの応答があります。私にはこれは正しくないようです。
たとえば、Javaは非常に明確に定義された標準です。基本的に、ブラウザのDOMをJava APIとして公開し、Java仮想マシン（JVM）をWebブラウザ内で実行します。スクリプトコードは、コンパイルおよび署名されたJARファイルの形式で、またはJavaScriptソースコードとして配信する必要があることを指定できます。ブラウザーがJavaScriptに遭遇した場合、専用のインタープリターを介して実行するか（現在のように）、またはJVMの上で Rhino を介して実行されます。jarファイルが検出されると、新しいクラスローダーとセキュリティサンドボックスが作成され、Javaバイトコードがメモリにロードされて実行されます。これにより、既存のWebページとの完全な下位互換性が確保され、ブラウザがシングルストロークでJVMで実行される数十の言語をサポートできるようになります。
その他の利点：
- JVMは10年間のパフォーマンス改善の恩恵を受けています。現在は非常に高速で、安定しており、成熟しています。解釈されたJavaScriptに比べてパフォーマンスが大幅に向上すると思います。
- クライアント側のアプリが大きく複雑になるにつれて、JavaおよびScala）のような構造化された型付き言語の利点が増加します。
- マルチコアコンピューティング用に最適化されたコレクションライブラリであるScalaを通じて、真のマルチスレッドにアクセスできます。
- ブラウザー内で何千ものオープンソースJavaライブラリーのいずれかを使用できます。
- ブラウザは、openGLなどのライブラリを通じて、高度なグラフィックスおよびグラフィックスカードコンピューティング機能へのアクセスを提供できます。
- クライアント側とサーバー側でJavaを実行している場合は、非常に圧縮されたバイナリオブジェクトグラフシリアライゼーション= Webページの読み込みと実行を高速化することにより、クライアント/サーバー通信からさらに利益を得ることができます。
Haskel、LISP、Python（おそらく他の言語）など）、他の言語をJavaScriptにコンパイルするツールの例がいくつかあります。したがって、これらの言語の1つで作業したい場合は、そうすることができます。
そして、大学の教授の一人がJavascriptでスキーマ実装を書いたと思います。スキームが好きなら、それもできます。
私は、JavaScriptがWebの標準言語としてさらに地位を固めると信じています。サーバー側のJavaScriptが増加しています。サーバーでのこの強力な言語の実装の例をいくつか示します。
POW WebサーバーSJS -Firefox拡張機能またはXULRunnerアプリケーションとして実行されるPOW Webサーバーのサーバー側JavaScript。 SJSは、データベースに接続してクライアント側のコンテンツを生成できるという点で、ApacheのPHP）と同様の役割を果たします。
NodeJS -イベントベースのモデルを使用するサーバー側JavaScript。これは、Googleの V8 JavaScriptエンジン を使用して構築されています。 NodeJSは、スケーラブルなネットワークプログラムを構築するためのツールとして宣伝されています。 「Hello World」Webサーバーは、わずか6行で記述できます。
Jaxer -
runat="server"を含むすべてのスクリプトブロックをサーバーサイドJavaScriptとして解釈するJavaScriptサーバー。 Webアプリケーション全体をJavaScriptで作成できます。Rhino-JavaScript for Java -Mozillaは、Javaで実行されるこのサーバー側JavaScript実装を作成しました。これは基本的に Querces PHP for Java 、Jython、JRuby、およびJVMで実行される他の言語の多くの他の抽象化）と同様の概念です。Rhinoは通常、埋め込みに使用されますJavaScriptをJavaに入れて、スクリプトツールをエンドユーザーに提供しますが、別の言語でビジネスロジックを書き直さなくても、クライアント側のコードをサーバーに移動するために使用することもできます。
JQuery Claypool -サーバー上のJQueryの機能を使用するサーバー側JavaScriptフレームワーク。とてもかっこいい！これは、ブラウザーのEnvJsサーバー側JavaScript実装を使用して開発されています。
EnvJs -Rhinoの上に構築されたヘッドレスブラウザ。
これらの実装とフレームワークの多くが実証しているのは、JavaScriptがWeb開発において非常に強力な勢力になり、コミュニティのリーダーがJavaScriptをサーバーに移動し始めたことです。 JavaScriptは非常に強力な関数型プログラミング言語であり、時が経つにつれ、JavaScriptは進化していくと思います。
要約すると、代わりにこの単一のブラウザー言語をサーバーに移植して、そのギャップをより統一された方法で埋めることができる場合、他の言語をブラウザーに移植することは矛盾しているようです。
人々は組み込みの多様性の欠如を2つの方法で回避しました：フラッシュやJavaアプレットのようなプラグインを使用することと、jqueryやgoogle web toolkit。十分に人気のある新しい開発スタイルがあれば、人々はそれを取り入れるための方法を見つけるでしょう。
JavaScriptで.netランタイムを作成すると、それが人気になると、特定のサークルがインターネットであなたの名前を永遠に呪います。