現在、完全にサポートされている唯一の言語であり、ブラウザーでのDOMツリー操作の事実上の標準はJavaScriptです。設計上の深い問題があり、初心者にとってバグとセキュリティホールの地雷原になっているようです。

次世代ブラウザでのDOMツリー操作とHTTPリクエストに、（JavaScriptだけでなく）あらゆる種類のより良い（再設計された）言語を導入するための既存または計画中の取り組みを知っていますか？はいの場合、Firefoxなどに統合するためのロードマップは何ですか？いいえの場合、（相互運用性の一部として）ブラウザープラットフォームでサポートされる唯一の言語はJavaScriptである必要がありますか？

私はすでにjQueryを使用しており、「javascript：良い部分」も読んでいます。確かに提案は良いですが、私が理解できないことは、なぜJavaScriptだけなのかです。サーバーサイド（お気に入りのosプラットフォーム）では、fortranを含むすべての言語でDOMツリーを操作できます。クライアント側（ブラウザプラットフォーム）がJavaScriptのみをサポートするのはなぜですか？

JavaScriptの問題は言語自体ではなく、完全に優れたプロトタイプで動的な言語です。OOのバックグラウンドを持っている場合は、学習曲線が少しありますが、言語のせいではありません。

ほとんどの人は、Javascriptは似た構文と似た名前を持っているのでJavaのようであると思いますが、実際はもっともっとLispのようです。実際には、DOM操作に非常に適しています。

実際の問題は、ブラウザによってコンパイルされることです。つまり、クライアントによって非常に異なる方法で機能します。

ブラウザによって実際のDOMが異なるだけでなく、パフォーマンスとレイアウトにも大きな違いがあります。

問題の説明を編集してください

複数のインタプリタ言語がサポートされていたとしましょう-それでも同じ問題があります。さまざまなブラウザは依然としてバグがあり、異なるDOMを持っています。

さらに、ブラウザーにインタープリターを組み込むか、プラグインとして（ページを表示する前に確認できる）なんらかの方法でインストールするインタープリターを言語ごとに用意する必要があります。Javascriptの一貫性を確保するには、長い年月がかかりました。

コンパイルされた言語を同じように使用することはできません。そのため、実行内容を簡単に調査できない実行可能ファイルを導入します。多くのユーザーは実行しないことを選択します。

では、コンパイルされたコードのサンドボックスについてはどうでしょうか？私にはJavaアプレットのように聞こえます。またはFlashのActionScript。またはSilverlightのC＃。

ある種のIL標準はどうですか？それはより多くの可能性を秘めています。必要な言語で開発し、それをILにコンパイルします。ILは、ブラウザーがJITを実行します。

例外として、JavaScriptはすでにそのILのようなものです-GWTを見てください。Javaでプログラムを作成できますが、HTMLおよびJSとして配布できます。

問題のさらなる説明に従って編集する

JavaScriptは、ブラウザーでサポートされている唯一の言語ではありませんでした。InternetExplorerの暗黒時代に戻ると、IEで実行するためにJavaScriptまたはVBScriptを選択できました。技術的にIEでもJavascriptを実行しなかった-それは走ったのJScriptを（主に単語のための日を支払うことを避けるためにJavaの、Oracleはまだ名前所有Javascriptを）。

問題は、VBScriptがMicrosoft独自のものであるということでしたが、それだけではあまり良くありませんでした。JavaScriptが機能を追加し、他のブラウザー（FireBugなど）で最高のデバッグツールを取得している間、VBScriptはIEのみで、ほとんどデバッグできません（IE4 / 5/6の開発ツールは存在しませんでした）。一方、VBScriptも拡張されて、OSで非常に強力なスクリプトツールになりましたが、ブラウザーではこれらの機能は利用できませんでした（そして、機能が巨大なセキュリティホールになったとき）。

VBScriptを使用する企業の内部アプリケーションがいくつかあり（一部はセキュリティホールに依存しています）、IE7を実行しています（MSが最終的にそれを強制終了したため、IE6のみが停止しました）。

Javascriptを現在の状態にすることは悪夢であり、20年を要しました。まだ一貫したサポートがなく、一部のブラウザーでは言語機能（1999年に指定）がまだ欠けており、多くのシムが必要です。

ブラウザーで解釈するための代替言語を追加すると、2つの主要な問題に直面します。

• すべてのブラウザーベンダーに新しい言語標準を実装させる-20年の間にJavascriptでまだ管理していないもの。

• 第二言語は潜在的にあなたが既に持っているサポートを薄め、（例えば）IEが二級のJavascriptサポートを持つことを可能にしますが（素晴らしい）VBScriptです。ブラウザごとに異なる言語でコードを記述したくありません。

Javascriptは「完成」していないことに注意してください。新しいブラウザでより良くなるように進化しています。最新バージョンでは、先にブラウザの実装のの年であり、それらは次のものに取り組んでいます。

JavaScriptにコンパイル

現時点では、Javascriptにコンパイルする言語を使用することが、よりスマートなコードを記述しながらすべてのプラットフォームに到達するための唯一の現実的な方法であるように思われます。新しいオファリングでは、1つ以上のベンダーが急いでそれを出荷しない理由が常にあります。

（しかし、私はこれが問題だとは本当に思っていません。Javascriptは今ではうまく最適化されています。マシンコードも手動で書かれた場合は安全ではありませんが、コンパイルターゲットおよび実行言語としては正常に機能します。）

非常に多くのオプション

Javascriptにコンパイルする言語のプールが増え続けています。かなり包括的なリストはここにあります：

• Coffeescript WikiでJSにコンパイルされる言語のリスト

注目すべき

私が注目に値すると思ういくつかを言及します（間違いなく、私が知らないいくつかの宝石を無視しています）：

• Spiderは2016年に登場しました。Go、Swift、Python、C＃、CoffeeScriptの最高のアイデアを取り入れていると主張しています。タイプセーフではありませんが、いくつかのマイナーな安全機能があります。

• Elm：Haskellはそれらすべての中で最も賢い言語かもしれません、そしてElmはJavascriptのHaskellの変形です。高度な型認識と簡潔さを備えており、リアクティブテンプレートやMVCスパゲッティに代わる機能的なファンクショナルリアクティブプログラミングを提供します。しかし、それは手続き型プログラマにとってはかなりのショックかもしれません。

• GoogleのGoは、簡潔さ、シンプルさ、安全性を目的としています。GoコードはGopherJSによってJavascriptにコンパイルできます。

• Dartは、Javascriptに取って代わるGoogleの後の試みでした。これは、オプションの型指定を備えたC / Javaのような構文によるインターフェースと抽象クラスを提供します。

• HaxeはFlashのActionScriptに似ていますが、複数の言語をターゲットにできるため、コードをJava、C、Flash、PHP、JavaScriptプログラムで再利用できます。タイプセーフで動的なオブジェクトを提供します。

• Opalangは、Javascriptに構文シュガーを追加して、直接データベースアクセス、スマートな継続、型チェックを提供し、クライアント/サーバーの分離を支援します。（NodeJSとMongoDBに関連付けられています。）

• GorillaScript、「いくつかの一般的なエラーを回避しようとしながら、ユーザーに力を与えるように設計されたJavaScriptへのコンパイル言語」Coffeescriptに似ていますが、より包括的で、安全性を高め、反復的な定型パターンを削減するための追加機能をたくさん提供しています。

• LiteScriptは、CoffeescriptとGorillaScriptの中間にあります。「インライン」コールバック用の非同期/降伏構文を提供し、変数のタイプミスをチェックします。

• MicrosoftのTypeScriptはJavascriptの小さなスーパーセットであり、関数の引数に型制限を設定することができます。これにより、いくつかのバグをキャッチできる場合があります。同様に、BetterJSでは制限を適用できますが、純粋なJavaScriptでは、追加の呼び出しを追加するか、JSDocコメントでタイプを指定します。そして今Facebookは型推論をさらに実行するFlowを提供しています。

• LiveScriptはCoffeescriptから派生したもので、簡潔さで人気がありましたが、私にはあまり読みやすくはありません。おそらくチームに最適ではありません。

選ぶ方法は？

代替言語を選択する際には、考慮すべきいくつかの要素があります。

• 他の開発者があなたのプロジェクトに将来参加する場合、彼らがスピードを上げてこの言語を習得するのにどれくらいの時間がかかりますか、あるいは彼らがすでにそれを知っている可能性は何ですか？

• 言語に含まれる機能が少なすぎる（コードが定型文でいっぱいになる）か、または機能が多すぎますか（習得に長い時間がかかり、それまでは有効なコードが解読できない可能性があります）？

• プロジェクトに必要な機能はありますか？（プロジェクトには型チェックとインターフェースが必要ですか？ネストされたコールバック地獄を回避するためにスマートな継続が必要ですか？多くの反応性がありますか？将来的に他の環境をターゲットにする必要があるかもしれません？）

未来...

Jeff Walkerは、TypeScriptもDartもCoffeescriptも適切な解決策を提供していないと考える理由を含め、「Javascriptの問題」に関する一連の示唆に富むブログ投稿を執筆しました。結論として、彼は改善された言語に望ましいいくつかの機能を提案しています。

ブラウザプラットフォームでサポートされている言語はJavaScriptのみである必要がありますか？

はいといいえ。JavaScriptにコンパイルするDart by Googleと呼ばれる別の方法があり、jQueryのようにDOM操作を少し簡単にしようとします。実験してみるのも楽しいかもしれません。ぜひチェックしてみてください。

• グーグルからダーツ言語を参照してください
• MicrosoftからTypeScript言語を参照してください

こちらもご覧ください

• エルム
• カル

ある時点でJavascriptの扱いが悪かったことは悪名高かったことは事実ですが、それ以来、Web開発コミュニティは長い道のりを歩んできました。代わりに、jQueryをご覧になることをお勧めします。簡単で、さまざまな問題をすべて抽象化します。

そして、全面的に機能する代替手段は本当にありません。Flashが思い浮かびますが、それもECMAスクリプトであり、ほとんどの場合、やりすぎです。

短期的には、jQueryなどを使用して、ブラウザーの非互換性を隠します。長期的には、SilverlightやAdobe AIRのようなテクノロジーにより、これは将来、非常に異なる地雷原（まだ地雷原）になる可能性があります。

Doug Crockford がGoogleに講演を行い、 JavaScriptの悪い部分と良い部分とその将来について詳しく説明しました。それは実際には1999年以降ほとんど変わっていません-これは良いことだと言えます（ほとんどすべてのブラウザーは、その制限を認識している限り、同じコードを実行できます）。非常に強力であることが判明した誤解がほとんどでした。

DOM操作については、JQueryを、ひどいDOM APIのほとんどを、より簡単に記述できる非常にエレガントなコードに書き込むのが面倒な操作に置き換えるクライアント側ライブラリとして見てください。

JavaScriptに深い問題があるとお考えの場合は、Doug Crockford著のJavaScript：The Good Partsをお勧めします。（またはGoogleが「Crockford JavaScript」を検索して、彼が行ったいくつかのビデオプレゼンテーションを見つけます。）Crockfordは、安全なサブセットと実践のセットをスケッチし、特に避けるべき言語の一部をリストしています。

私は、DOMを操作する事実上の手段としてJavaScriptを置き換える計画を知りません。したがって、安全かつ適切に使用することをお勧めします。

クライアント側では、JavaScriptがDOMを操作する唯一の方法です。サーバー側では、さまざまな方法があります。

Internet Explorerはプラグ可能なスクリプト言語をサポートしていますが、JScript以外にIEに確実に含まれているのはVBScriptだけです。

私が見た限りでは、ブラウザの動的言語に対する一般的な偏見があり、JavaScriptはこのニーズを十分に満たしているため、ネットワークの影響により他の言語がスターターではなくなります。この言語は実際には非常に強力ですが、ブラウザーでのその実装は多くが望まれていません。

顧客/訪問者を特定のブラウザーに制限したい場合や、プラグインのインストールを要求したい場合は、MS Silverlightをご覧ください。読みやすい概要はWikipediaにあります。Silverlight 2では、C＃、IronPython、IronRuby、VB.NETなどで記述したクライアント側のコードを実行できます。MonoプロジェクトからのSilverlight の無料のMoonlightクローンは、同じ機能をLinuxにもたらすことを約束します。

実際には、Webアプリやサイトのほとんどの開発者は、Silverlight（および最終的にはMoonlight）が現在配信できるよりも幅広いオーディエンスにリーチすることを好みます。つまり、Javascriptや、おそらくFlash（同様のプログラミング言語であるActionscriptを使用）にこだわります。

そのため、他の何かについて相当なマインドシェア、採用、牽引力を獲得することは、エンジニアとマーケティング予算の大規模なグループ、およびフリーソフトウェアプロジェクトを側に持つMicrosoftにとってさえ、困難な戦いとなることが証明されています（独自のロックインに関する懸念を和らげるため） ）-これは、たとえばMozilla Foundationの側で、そのような目標に向かって推進することに関心がほとんどない理由を説明するのに役立ちます。「相互運用性は別として」と言いますが、Silverlightの進捗状況を観察すると、相互運用性の問題がここで最も重要になります。

すでに述べたように、プラグインを介してブラウザーで実行できるFlash（Javascriptから派生した言語であるActionScript）とSilverlight / Moonlight（IronPython、IronRuby、JScript、VBScript、C＃）があります（最初のプラグインははるかにユビキタスです）。 。

Rubyが好きな場合は、別の方法としてHotRubyを使用することもできます。これは、ブラウザーで実行されるJavaScriptのRuby実装です。まだあまり成熟していませんが、ご覧になれます。

私が言及していないことの1つ（ああ、私が書いているときにAlcidesがHotRubyを言及し、NosrednaがGWTとScript＃を言及したことを確認します）、そこに[言語を挿入]の実装がいくつかあることを捨てたいと思います- JavaScript（例：Ruby、Python、C＃、Java、Obj-J / Cappuccino [Obj-C / Cocoaに類似]またはProcessing [Canvas]をクライアントまたはデプロイ前にJavaScript に変換できるトランスレーター [および一部そのうち、さまざまな抽象化ライブラリも備えています]）。もちろん、クライアントで翻訳する場合はパフォーマンスのオーバーヘッドがありますが、別の言語に慣れている場合はある程度の柔軟性が得られます。

ただし、個人的には、JavaScriptを愛することを学ぶことをお勧めします。優れた強力な言語であり、一度理解すればかなりエレガントです。私は逆のジレンマに直面しており、私のニーズのすべてを満たすサーバー側のJavaScript / DOMソリューションを実現するために少しばかり苦労しています。/一方的な意見

いいえ。JavaScriptはそれだけですが、進化します。次のバージョンは「JavaScript Harmony」であり、それをGoogle化すれば、より多くを学ぶことができます。

時々、JavaScriptと一緒にバイトコードインタープリターをブラウザーに配置することをお勧めします。少なくともしばらくの間は、おそらく起こりません。

私はたまたまJavaScriptが大好きです。しかし、JavaをJavaScriptにコンパイルするGWTやC＃をJavaScriptにコンパイルするScript＃など、他のソリューションもあります。

Jquery（まだjavascriptですが）は、ほとんどすべてのブラウザーをサポートするのに役立ち、学習するのはそれほど難しくありません:)

JavaScriptはウェブの英語です。英語は歴史的に広がりました。なぜならそれは様々な国を征服する強い海軍を持っていたからです。これは、JavaScriptでWebを征服した大企業に匹敵します。これは、ヨーロッパの複数のソース（ギリシャ語、ラテン語、ゲルマン語、フランス語、中国語、インド語など）を組み合わせた言語です。JavaScriptは他の言語（構造、オブジェクト指向、関数）から長年にわたって多くの概念を借用しました。英語はさまざまな場所で話され、方言やアクセントがわずかに異なるため、理解が難しくなる可能性があります。JavaScriptがブラウザによって解釈が少し異なるように、JavaScriptの解釈も少し異なります。

英語は最初は簡単に習得できますが、発音に一貫性がなく、規則よりも例外があります。JavaScriptのように、サプライズを提供するために常にそこにあります。

アクセントはさまざまですが、JavaScriptはWebの共通語です。英語ではなく、ここで英語で書く場合と同様に、すべてのWebブラウザーはある程度の英語を理解しています。IE6は履歴書で流暢だと言っている人のような人ですが、外国語としての英語の2週間のコースにしか行きませんでした。

エスペラント語など、世界の主要言語として英語に取って代わる試みがありました。しかし、地球上のほとんどの人がある程度英語を話すため、それらすべてが失敗しました。同様に、JavaScriptに代わるより良い代替手段を導入することは困難です。

Javascriptがすぐに置き換えられるとは思いません。リッチクライアントに対するまったく異なるアプローチについては、FlashベースのテクノロジーであるFlexを調査することをお勧めします。

多分haxe（haxe.orgを参照）のようなものがあなたを助けるでしょう。これはJavaScriptよりもクリーンに見える言語であり、JavaScriptにコンパイルできるため、ブラウザー内で実行できます。

これはあなたの質問への直接の答えではないことは知っていますが、それでもあなたにとって興味深いかもしれないと思いました。

多くの人々は、Javascriptが今までになく最高で最もきれいな言語ではないことを理解しています。ただし、現在ブラウザでサポートされているため、別の言語を導入することは非常に困難です。別のブラウザ戦争は必要ありません。

これが、クライアント側の別の言語に切り替える計画を知らない理由です。

しかし、DOMモデルと、それをどのように扱うかについて考え始めれば、JavaScriptはそれほど悪くないと思います。JSで厄介な多くのことは、DOMモデルが機能する方法の結果です。