質問
現時点で完全にサポートされている唯一の言語であり、ブラウザーでの DOM ツリー操作の事実上の標準は JavaScript です。初心者にとってはバグやセキュリティホールの地雷原となるような深い設計上の問題があるようです。
次世代ブラウザでの DOM ツリー操作と HTTP リクエスト用に、あらゆる種類の (JavaScript に限らず) より優れた (再設計された) 言語を導入する既存の、または計画されている取り組みをご存知ですか?「はい」の場合、たとえば Firefox への統合のロードマップは何ですか?「いいえ」の場合、(相互運用性とは別に) JavaScript をブラウザ プラットフォームでサポートされる唯一の言語にする理由は何ですか?
私はすでに jQuery を使用しており、「javascript:良い部分」。確かに、提案は良いのですが、私が理解できないのは次のとおりです。なぜJavaScriptだけなのでしょうか?サーバー側 (お気に入りの OS プラットフォーム) では、Fortran を含むあらゆる言語で DOM ツリーを操作できます。クライアント側 (ブラウザ プラットフォーム) が JavaScript のみをサポートしているのはなぜですか?
解決
JavaScript の問題は言語自体ではありません。JavaScript は完全に優れたプロトタイプ化された動的言語です。OO のバックグラウンドを持っている場合、学習には少し時間がかかりますが、それは言語のせいではありません。
ほとんどの人は、JavaScript は構文と名前が似ているため Java に似ていると考えていますが、実際には Lisp にもっと似ています。実際、これは DOM 操作に非常に適しています。
本当の問題は、ブラウザによってコンパイルされることです。つまり、クライアントに応じて動作方法が大きく異なります。
実際の DOM がブラウザーによって異なるだけでなく、パフォーマンスとレイアウトにも大きな違いがあります。
問題の説明に従って編集してください
複数のインタープリター言語がサポートされていると仮定します。それでも同じ問題が発生します。さまざまなブラウザにはまだバグがあり、異なる DOM を持っています。
さらに、言語ごとにブラウザにインタプリタを組み込むか、プラグインとして何らかの方法でインストールする必要があります(ページを表示する前にチェックできる)。JavaScript の一貫性を保つには長い時間がかかりました。
コンパイルされた言語を同じ方法で使用することはできません。その場合、その機能を簡単に精査できない実行可能ファイルを導入することになります。多くのユーザーはそれを実行しないことを選択するでしょう。
では、コンパイルされたコード用のサンドボックスのようなものはどうでしょうか?Java アプレットのように思えます。または Flash の ActionScript。または Silverlight の C#。
ある種の IL 規格についてはどうですか?その方がより可能性が高いのです。任意の言語で開発し、それを IL にコンパイルし、ブラウザーが JIT します。
ただし、JavaScript はすでにその IL のようなものです - 見てください。 GWT. 。Java でプログラムを作成し、HTML および JS として配布できます。
問題をさらに明確にした後、編集します
JavaScript はブラウザーでサポートされる唯一の言語ではありません、あるいはそうではありませんでした。Internet Explorer の暗黒時代には、IE で実行するのに Javascript か VBScript を選択できました。厳密に言えば、IE は Javascript さえ実行していませんでしたが、実行されました。 JScript (主に、その言葉に対して Sun にお金を支払わなくて済むようにするため) ジャワ, 、オラクルは現在でもその名前を所有しています。 JavaScript).
問題は、VBScript が Microsoft の専有物であるだけでなく、あまり優れたものではないということでした。Javascript が機能を追加し、他のブラウザ (FireBug など) でトップクラスのデバッグ ツールを取得している一方で、VBScript は IE のみであり、ほとんどデバッグ不可能でした (IE4/5/6 の開発ツールは存在しませんでした)。一方、VBScript も拡張され、OS 内で非常に強力なスクリプト ツールになりましたが、これらの機能はどれもブラウザーでは利用できませんでした (そして、利用可能になったときには大規模なセキュリティ ホールになりました)。
VBScript を使用する企業内部アプリケーションがまだいくつか存在し (一部はこれらのセキュリティ ホールに依存しています)、それらは依然として IE7 を実行しています (MS が最終的に IE6 を廃止したため、IE6 が停止されただけです)。
Javascript を現在の状態にするのは悪夢のようなもので、20 年かかりました。一部のブラウザでは言語機能 (1999 年に規定) が依然として欠落しており、多くの shim が必要であるため、まだ一貫したサポートがありません。
ブラウザで通訳するための代替言語を追加すると、次の 2 つの大きな問題に直面します。
すべてのブラウザ ベンダーに新しい言語標準を実装させることですが、JavaScript については 20 年間まだ管理できていません。
第 2 言語は、既存のサポートを弱める可能性があり、(たとえば) IE は 2 流の Javascript サポートを備えていますが、(これもまた) 優れた VBScript をサポートします。異なるブラウザーに対して異なる言語でコードを書きたくありません。
JavaScript は「完成」したわけではないことに注意してください。新しいブラウザーでより優れたものになるよう、まだ進化しています。の 最新バージョン ブラウザの実装より何年も先を行っており、ブラウザは次の実装に取り組んでいます。
他のヒント
JavaScript にコンパイルする
今のところ、JavaScript にコンパイルされる言語を使用することが、よりスマートなコードを記述しながらすべてのプラットフォームにアクセスできる唯一の現実的な方法のようであり、これは今後も長期間続く可能性があります。新しい製品には、必ず 1 つ以上のベンダーが出荷を急がない何らかの理由があります。
(でも、これは特に問題ないと思います。Javascript は現在、適切に最適化されています。マシンコードも手作業で書かれた場合は安全ではありませんが、コンパイルターゲットおよび実行言語としては正常に機能します。)
非常に多くのオプション
JavaScript にコンパイルできる言語のプールは増え続けています。かなり包括的なリストは次の場所にあります。
- JS にコンパイルできる言語のリスト Coffeescript Wiki で
注目すべき
注目に値すると思われるものをいくつか挙げておきます (ただし、私が気づいていないいくつかの宝石は間違いなく無視しています)。
クモ 2016年に登場しました。Go、Swift、Python、C#、CoffeeScript の最高のアイデアを取り入れていると主張しています。タイプセーフではありませんが、いくつかのマイナーな問題があります 安全機能.
エルム:ハスケルはおそらく 最も賢い言語 Elm は Javascript 用の Haskell の亜種です。型認識性が高く、簡潔であり、以下を提供します。 関数型リアクティブプログラミング リアクティブ テンプレートや MVC スパゲッティの優れた代替品として。でもそれはかなりあるかもしれない 手続き型プログラマにとっては衝撃的.
Googleの 行く 簡潔さ、単純さ、安全性を目的としています。Go コードは次のようにして JavaScript にコンパイルできます。 GopherJS.
ダーツ これは、Google が後に Javascript を置き換えようとした試みでした。オプションの型指定を備えた C/Java のような構文を介してインターフェイスと抽象クラスを提供します。
ハクス Flash の ActionScript に似ていますが、 複数の言語をターゲットにする そのため、コードを Java、C、Flash、PHP、JavaScript プログラムで再利用できます。タイプセーフで動的オブジェクトを提供します。
オパラン JavaScript に糖衣構文を追加して提供します データベースへの直接アクセス, 、スマートな継続、型チェック、およびクライアント/サーバーの分離を支援します。(NodeJS と MongoDB に関連付けられています。)
ゴリラスクリプト, 「いくつかの一般的なエラーを防止しながら、ユーザーに権限を与えるように設計された、コンパイルして JavaScript に変換する言語。」 これは Coffeescript に似ていますが、より包括的で、安全性を高め、反復的な定型パターンを減らすための追加機能を多数提供します。
ライトスクリプト Coffeescript と GorillaScript の中間に位置します。「インライン」コールバックの非同期/yield構文と、変数のタイプミスのチェックを提供します。
マイクロソフトの TypeScript は、関数の引数に型制限を設定できる Javascript の小さなスーパーセットですが、これによりいくつかのバグが見つかる可能性があります。同様に BetterJS 追加の呼び出しを追加するか、JSDoc コメントで型を指定することにより、純粋な Javascript で制限を適用できます。そして今、Facebookが提供しているのは、 流れ さらに型推論を実行します。
ライブスクリプト これは、その簡潔さで人気があった Coffeescript から派生したものですが、私にはあまり読みにくいように思えます。おそらくチームにとっては最善ではないでしょう。
選び方は?
いつ 選択する 代替言語、いくつかあります 考慮すべき要素:
将来、他の開発者があなたのプロジェクトに参加する場合、彼らがこの言語を習得して学習するまでにどれくらい時間がかかりますか、あるいは彼らがすでにこの言語を知っている可能性はどれくらいですか?
この言語の機能は少なすぎますか (コードはまだ定型文でいっぱいになります)、それとも機能が多すぎますか (マスターするには長い時間がかかり、それまでは一部の有効なコードが解読できない可能性があります)。
プロジェクトに必要な機能はありますか?(あなたのプロジェクトには型チェックとインターフェイスが必要ですか?ネストされたコールバック地獄を避けるために賢明な継続が必要ですか?反応性が高いのでしょうか?将来的には他の環境もターゲットにする必要があるでしょうか?)
未来...
ジェフ・ウォーカーはこう書いています 考えさせられるシリーズ 「JavaScript の問題」に関するブログ投稿の数 (彼がどちらとも考えない理由を含む) TypeScript, 、 または ダーツ または コーヒースクリプト 適切な解決策を提供します。彼は、改良された言語に望ましい機能をいくつか提案しています。 結論.
ブラウザ プラットフォームでサポートされる言語は JavaScript だけでしょうか?
はいといいえ。Dart by Google と呼ばれる代替手段があり、これは JavaScript にコンパイルされ、jQuery と同様に DOM 操作を少し簡単にしようとします。試してみるのも楽しいかもしれませんので、ぜひチェックしてみてください。
- Googleから見る ダーツ言語
- Microsoft からの参照 TypeScript言語
こちらも参照
Javascriptが一点に対処するために悪名高く困難だったが、Web開発コミュニティは以来、長い道のりを歩んできましたことは事実です。代わりに、私は jQueryののを見てすることをお勧めします。それは簡単だし、すべての様々な問題を離れて抽象化します。
そして本当に軒並み仕事一切の選択肢はありません。フラッシュが頭に浮かぶが、それはあまりにもECMAスクリプトであり、それはおそらくオーバーほとんどのもののために殺すのだ。
短期では、私は、ブラウザの非互換性を非表示にするjQueryのようなものを使用すると思います。長期では、SilverlightのまたはAdobe AIRなどの技術は、将来的には、この非常に異なる地雷原(それでも地雷原)ことがあります。
ダグクロックフォードは詳細をGoogleに講演を行いましたJavaScriptとその未来の悪いと良い部品。良いことであると言うことができた(ほとんどすべてのブラウザでは、限り、あなたは自分の限界を認識しているのと同じコードを実行することができます)とダグはどこに良い部品を示す - それは実際には1999年以降では、すべてのあまり変わっていません非常に強力であることが判明誤解がほとんどでした。
DOMのmanipuluationの場合、書き込みが簡単で、コードのかなり優雅なビットへの書き込みに苦痛な操作でひどいDOMのAPIのほとんどを置き換えるクライアント側ライブラリとしてjQueryのを見てみます。
は、JavaScriptが深い問題を持っていることを考えているならば、私はのJavaScript、ダグクロックフォードの本をお勧めします:良い部品に。 (またはGoogle「クロックフォードJavaScriptは」彼が行うのいくつかのビデオプレゼンテーションを見つけるため。)クロックフォードは安全なサブセットをスケッチや慣行のセット、特に避けるために、言語の一部を示しています。
私は、DOMを操作するのデファクトの手段としてJavaScriptを交換する計画を知らないんです。だから、最高の安全かつそれをうまく使用することを学ぶ。
クライアント側のJavaScriptの面では、DOMを操作する唯一の方法です。サーバ側の面で多くの方法があります。
Internet Explorerは、プラグイン可能なスクリプト言語をサポートしています。
は、私の知る限り見てきたように、ブラウザでの動的言語への偏りの一般的な並べ替えがあるように思われる、とJavaScriptはそのネットワーク効果は、他の言語非スターター作る適切に十分なこのニーズを満たしているようです。ブラウザでの実装はまだ十分とは言えないものの、言語は、実際には非常に強力です。
顧客/訪問者を特定のブラウザに制限したい場合、また場合によってはプラグインのインストールを要求したい場合は、以下を検討してください。 MS シルバーライト -- 読みやすい概要が表示されます ウィキペディア. 。Silverlight 2 を使用すると、C#、IronPython、IronRuby、VB.NET などで作成したコードをクライアント側で実行できます。無料の 月光 Mono プロジェクトからの Silverlight のクローンは、同じ機能を Linux にもたらすことを約束しています。
実際には、Web アプリや Web サイトのほとんどの開発者は、Silverlight (そして最終的には Moonlight) が現在提供できるよりも幅広いユーザーにリーチすることを好みます。つまり、Javascript か、場合によっては Flash (同様のプログラミング言語である Actionscript を使用します) を使い続けることになります。
そのため、他の何かについてかなりのマインドシェア、採用、牽引力を獲得することは、大規模なエンジニア グループとマーケティング予算を持つ Microsoft にとってさえ困難な戦いであることが判明しています。 そして フリーソフトウェア プロジェクトも並行して行っています (プロプライエタリなロックインに関する懸念を軽減するため) -- これは、なぜ関心がほとんどないのかを説明するのに役立つかもしれません。Mozilla Foundation の側では、そのような目標に向かって突き進んでいます。「相互運用性は別として」とあなたは言います:しかし、Silverlight の進歩に関して私たちが観察していることを考慮すると、相互運用性の問題がここで最大の課題であることは明らかです...
、あなたは(最初のものはあまりされてプラグインを介して、ブラウザで実行することができますフラッシュ(JavaScriptから派生言語であるActionScriptの、)およびSilverlight /ムーンライト(IronPythonの、IronRubyの、JScriptでは、VBScriptの、C#)を持っています)よりユビキタスます。
あなたのRubyのような場合は、別の代替もあります。: HotRuby に、そのするJavaScriptでのRubyの実装ですブラウザで実行されます。それはまだ非常に成熟していないですが、あなたはそれを見てすることができます。
言及されていないことが 1 つあります (ああ、私が書いているときに Alcides が HotRuby について言及し、Nosredna が GWT と Script# について言及しました) が、そこで吐き出しておきたいのは、[言語を挿入]-on- の実装が多数あるということです。 JavaScript (例:変換できる翻訳者 ルビー, パイソン, C#, ジャワ, オブジェ/カプチーノ [Obj-C/Cocoa に類似] または 処理 [Canvas の場合] クライアント上またはデプロイメント前のいずれかで JavaScript に変換されます [また、その一部にはさまざまな抽象化ライブラリも搭載されています])。もちろん、クライアント上で翻訳される場合はパフォーマンスのオーバーヘッドが発生しますが、別の言語に慣れている場合は、ある程度の柔軟性が得られます。
ただし、個人的には、JavaScript を好きになることを学ぶことをお勧めします。これは優れた強力な言語であり、一度使い慣れると非常にエレガントになります。私は逆のジレンマに直面しており、すべてのニーズを満たす有能なサーバーサイド JavaScript/DOM ソリューションを手に入れようと懸命に努力しています。/一方的な意見
はありません。 JavaScriptがそれであるが、それは進化していきます。次のバージョン「JavaScriptの調和」であり、あなたがそれをGoogleにあれば、あなたはより多くを学ぶことができます。
さて、次に誰かがJavaScriptを一緒にブラウザにバイトコードインタプリタを置くことを示唆しています。おそらく、少なくともしばらくの間、発生しません。
私はJavaScriptを好きに起こります。しかし、JavaScriptにC#のをコンパイルしたJavaScriptとスクリプト#へのJavaをコンパイルGWT、など、他のソリューションは、あります。
jQueryの(まだジャバスクリプトけど)、それは本当にあなたが、彼らはほとんどすべてのブラウザのサポートを持っており、それは難しい学ぶことは本当にないのに役立ちます。)
JavaScriptは、ウェブの英語です。それは様々な国を征服し、強力な海軍を持っていたので英語は歴史的に広がりました。これはJavaScriptを使用してウェブを征服した大企業に匹敵します。これは、複数のヨーロッパの源(ギリシャ語、ラテン語、ゲルマン語、フランス語にもいくつかの中国とインドの言葉)から一緒に上書きさ言語です。 JavaScriptは、他の言語(構造、OO、機能)から年間を通じて概念の多くを借りました。英語は理解が困難なレンダリングすることができ方言やアクセントのわずかな変化、と別の場所で話されています。 JavaScriptは少し違った解釈異なるブラウザを持っているだけのような。
英語が最初に学ぶことは簡単ですが、それは非常に一貫性のない発音やルールよりも多くの例外があります。ただ、JavaScriptのようにそれは驚きを提供することは常にあります。
違うアクセントにもかかわらず、JavaScriptはウェブの共通語です。あなたが英語と英語でここに書くかもしれないと同じように、すべてのWebブラウザは、英語の理解をある程度持っています。 IE6は、彼が流暢だということを、彼の履歴書に述べている男のようであるが、唯一の外国語としての英語に2週間のコースに行ってきました。
例えば、世界の主要言語としての英語に取って代わるための試みがなされてきましたエスペラント。地球上のほとんどの人は、いくつかの英語を話すので、しかし、それらのすべてが、失敗しました。同じようにして、JavaScriptに、より良い代替手段を導入することは困難になります。
私はJavascriptがいつでもすぐに置き換えられますとは思いません。リッチクライアントとは全く異なるアプローチについて、あなたはFlashベースの技術であるFlexのを、調査したいかもしれません。
たぶん、haXeのようなものは、(haxe.orgを参照してください)あなたを助けることができます。これは、JavaScriptのよりクリーンなようで、それがブラウザ内で実行することができますので、JavaScriptにダウンコンパイルできる言語です。
私は、これはあなたの質問に直接答えではないことを知っているが、私はそれはそれにもかかわらず、あなたのために面白いかもしれないと思っています。
多くの人々はJavascriptが史上最高ときれいな言語ではないことを理解しています。しかし、それは、現在のブラウザでサポートされているので、別の言語を導入するのは非常に難しいでしょう。私たちは、単に別のブラウザ戦争は必要ありません。
私は別のクライアント側の言語に切り替えるの予定はないと知って、なぜこのは説明します。
しかし、私はあなたがDOMモデルについて考え始めると、どのように1はそれでうまくいく場合はJavascriptがそれほど悪くないと思います。 JSで散らかっている多くのものがDOMモデルの動作方法の結果である。