選択した言語でクライアント側のブラウザコードをコーディングできるようになりますか？[閉まっている]

正直言って、クライアント側のコードをJavaScriptで書くのは嫌です。控えめに言っても、私はこの言語のファンではありません。

ブラウザーが中間の仮想マシン（CILやJVMなど）ではなくプログラミング言語をサポートしているのは馬鹿げているように思えます。後者の場合、プログラマーは、1つの固定されたプリセット言語ではなく、選択した言語（ある程度）で書くことができます。この言語は、CIL / JVM /何でも変更するだけで、すべての主要なブラウザをアップグレードする必要があるため、より急速に進化する可能性があります。古いブラウザエクスペリエンスに影響を与えずに言語機能を追加できます。

中間言語がもたらす多大な労力の節約はよく知られています。JavaScript以外、特に既に設計、開発、最適化された仮想マシンでブラウザの「スクリプト」を促進するイニシアチブはありますか？勢いはありますか？

あなたの質問に答えるために、はい、JavaScriptを非推奨にしてWebスクリプト用のよりまとまりのある言語を支持する努力がなされています。Googleは、Dart言語の背後に多くの推力を置いています。Dartには、Chromeに既に埋め込まれている独自のVMがありますが、他のブラウザーがまだそれを採用しているかどうかはわかりません。CoffeeScriptと呼ばれるかなり有望な言語もあります。

HaXeと呼ばれる非常に野心的なプロジェクトもあります。これは、開発プラットフォームのホスト全体を単一の言語で統合することを目的としています。

Javascriptを嫌うのはあなただけではないと信じていますが、すぐにはどこにも行かないと思います。言及されているが湧き始めている:)

Javascript自体は、他の言語をコンパイルできる仮想マシンを定義する中間言語と見なすことができます。GWTのようなプロジェクトでは、この概念はすでに始まっています。最初から設計するものではないかもしれませんが、すでに「お気に入りの言語」をJavascriptにコンパイルできることが現実になりつつあります。

基本的にいいえ。あなたはJavascriptにかなりこだわっています。

そうは言っても、過去には他の言語（javaアプレット、vbscriptなど）を取り入れる努力がありました。これらのそれぞれは、javascriptが統合されているため、javascriptが持つ牽引力を得ることはありませんでした。

参照しているものをビルドする唯一の方法は、仮想マシンで実行され、コンパイルされたクライアント側で実行されるスクリプト言語を作成することです。次に、すべてのコードがすべてのブラウザーで実行されるように、各ブラウザーが仮想マシンを独自のコードベースに実装する必要があります。次に、すべてのブラウザーが同じ方法でコマンドを実行できるように、何らかの標準を用意する必要があります。もちろん、ブラウザは独立して作成されるため、開発者が留意しなければならない奇妙な点があるでしょう。

しかし、今ではJavascriptについて説明しました。

最終的に、あなたの選択は次のとおりです。

1. Javascriptに慣れる
2. Javascriptにコンパイルされる言語を使用してみてください。（Javascriptを検証する必要があることに注意してください。これにより、オプション1に戻ります。）
3. actionscript（Flash）、ActiveX、javaアプレット、.Net（SilverLight）など、ブラウザのプラグインとして存在する言語を使用します。これにより、複数のベンダー/言語の実装に関する問題は回避されますが、言語は統合されません。

基本的に、統合言語が必要な場合は、Javascriptに縛られています。

実際、Ecma規格で説明されているように、javascriptは嫌いではありませんが、さまざまなブラウザーでの奇妙な実装、嫌なもの、バグ、wtfsが嫌いです。サーバーサイドのJavascriptは実際には非常に楽しいものです。また、DOMモデルは、クライアント側のJavaScriptの80％の痛みの原因です。

それでも別の言語を使用したい場合は、GWTを使用して、基本的にJavaを記述し、（（い）javascriptにコンパイルするか、JSにコンパイルされるJSの構文糖であるCoffeeScriptを使用できます。

この質問は時々ポップアップします。

Javascriptだけでなく、スクリプトタグに他の言語を使用しないのはなぜですか

昔、IEはJavascriptの代替としてVBを導入しました。私はあなたがすでにこれがどうやって標準地獄につながるかを見ることができると思います...

では、なぜ共通の標準中間言語ではないのでしょうか？

Brendan Eichの古いポッドキャストで、近い将来に中間バイトコード言語が表示されない理由を説明しています。

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

基本的な問題は、中間言語（CILやJVMバイトコードなど）がジェネリックになろうとする一方で、ほとんどの場合、それらが低レベルになり、コンパイルされた元の高レベル言語に縛られすぎることです。たとえば、JVMで末尾再帰関数を実際に実装することはできません。低レベルのバイトコード抽象化に早すぎる段階で結合した場合、実装できない他の言語機能や実装の選択肢はどれですか。

一方、Javascriptは、確立されたセマンティクスと複数の異なる効率的な実装を備えた柔軟な高レベル言語です。将来私たちが目にするかもしれないのは、中間言語としてのJavascriptそのものです -残念ながら、これはやや未熟であり、今日ではJSにコンパイルされる言語はほとんどありません。

はい。すでにDart、Coffeescript、JavaをJavascriptにコンパイルできます。Emscriptenがあります。これは、Javascriptバイトコードを生成するためのLLVMのコンパイラバックエンドです（LLVMはかなりの数の言語を処理していると思います）。

しかし、JSにコンパイルする以外に、短期間ではありません。IE6は10歳で、まだ蹴っています。現在のブラウザ（他の言語をサポートしていない）がそれほど長く生き残らないことを願っていますが、数年は存続し、「Javascriptのみをサポートするブラウザをサポートする必要があり、 JavaScript3を使用する必要があります。CSS3と言うよりもはるかに難しい方法で、あなたのサイトはCSS3なしで動作するかもしれませんが、クライアント側のスクリプトなしで動作するようにしてください。

あなたは運がいいかもしれません。これは、webkit-devフォーラムへの投稿の冒頭の段落です。

今日、多くの言語がJavaScriptにコンパイルされ、Web上で実行されます。別の方法として、WebKitのさまざまな言語ランタイムをJavaScriptと一緒にWebページで実行できるようにすることを試みてきました...

ここからメッセージの残りを見ることができます。

JavaScriptはまさにブラウザの魂です。そのため、新しい試みの大半はJavaScriptを生成しています（CoffeeScriptは明確な例です）。
GWTでは、クライアント側のロジックをJavaプログラミング言語でコーディングし、ツールキットでJavaScriptを生成します。

Lijuコーディングをしている場合、ClojureScriptは興味深いプロジェクトです。

だから、JavaScriptは何に関係なく見える。（WebのCOBOLでしょうか？）。

「どんな顧客でも、それが黒である限り、彼が望むどんな色でも塗られる車を持つことができます。」 - ヘンリー・フォード

javascriptを対象とするコンパイラは既に多数あり、javascriptにコンパイルする言語を選択できます。

中間言語の価値を議論するリンクは、ネットワークを介して出荷され、クライアントマシンで実行されるコードを提供することではなく、コンパイラスイートの実装の文脈でそれらを議論します。Javascriptはそのための最良の形式ではないかもしれませんが、何であれ、CILやjavaバイトコードにあまり似ていません。

JavaScriptが嫌いなら、C、Fortran、C ++が支配する組み込み、科学、またはゲーム開発の分野に移動することをお勧めします。基幹業務アプリはWebに移行しつつあり、それはJavascriptを増やすことを意味します。