標準のブラウザ仮想マシンではなくJavaScriptを使用する理由
特殊な言語（実際には特殊なパラダイム）を使用するのではなく、ブラウザーでホストされる標準化された仮想マシンを使用して一連の言語（Java、Python、Rubyなど）をサポートすることは意味がありませんか？クライアントスクリプト専用ですか？
提案を明確にするために、WebページにはJavaScriptなどの高レベル言語ではなくバイトコードが含まれます。
JavaScriptは進化上の理由により、現在私たちが取り組まなければならないものであるという現実的な現実を理解していますが、長期的にはもっと考えています。下位互換性に関しては、インラインJavaScriptを一定期間同時にサポートできない理由はありません。もちろん、JavaScriptはブラウザー仮想マシンでサポートされている言語の1つである可能性があります。
はい、そうです。確かにタイムマシンがあれば、戻ってJavascript機能の多くが異なるように設計されていることを確認することは大きな楽しみです（そして、IEのCSSエンジンを設計した人々がITに参入しないようにすること）。しかし、それは起こらないでしょう、そして私たちは今それで立ち往生しています。
やがて、Webの「マシン言語」になり、他のより適切に設計された言語とAPIがコンパイルされる（そして異なるランタイムエンジンの脆弱性に対応する）のではないかと思います。
ただし、これらの「より適切に設計された言語」は、Java、PythonまたはRuby。そのユースケースを考えると、これらの言語のどれよりもうまくやることができます。
JavaScriptは優れた言語だと思いますが、クライアント側のWebアプリケーションを開発する際には選択肢が欲しいです。レガシーの理由から、私たちはJavaScriptにこだわっていますが、そのシナリオを変えることを探しているプロジェクトやアイデアがあります。
- Google Native Client ：ブラウザーでネイティブコードを実行するためのテクノロジー。
- Emscripten ：javascriptへのLLVMバイトコードコンパイラ。 LLVM言語をブラウザーで実行できるようにします。
- アイデア：Monoの作成者によるブラウザの.NET CLI： http://tirania.org/blog/archive/2010/May-03.html
JavaScriptは長い間使用されると思いますが、遅かれ早かれ変更されます。ブラウザで他の言語を使用したい開発者が非常に多くいます。
questionに答える-いいえ、意味がありません。
現在、多言語に最も近いものは、VMです。JVMとCLRです。これらは正確に軽量な獣ではありません。ブラウザの複雑さ。
既存のソリューションよりも優れた新しい多言語VMを書くことができるという考えを調べてみましょう。
- 安定性が遅れています。
- あなたは複雑さに遅れをとっています（複数の言語にわたって一般化しようとしているため、方法、方法、背後にあります）
- 採用が遅れている
だから、いや、それは意味がありません。
これらの言語をサポートするには、ブラウザのスクリプトのコンテキストで意味をなさない部分を切り詰めて、APIをかなり強力に削除する必要があります。ここで行われる膨大な数の設計上の決定と、エラーの大きな機会があります。
機能の面では、おそらく本当にとにかくDOMを操作しているだけなので、これは本当に構文と言語のidomの問題です。価値がある？"
念頭に置いて、サーバー側のスクリプティングは、どの言語でも使用できるため、onlyはクライアント側のスクリプティングです。それは比較的小さなプログラミング分野であるため、複数の言語を取り入れることの利点は疑わしいです。
どの言語を取り入れると意味がありますか？ （警告、主観的な資料が続きます）
Cのような言語を持ち込むことは、金属を操作するために作られているため、意味がありません。ブラウザでは、実際に利用できる金属はあまりありません。
Javaのような言語を使用することは意味がありません。なぜなら、それに関する最高のことはとにかくAPIであるためです。
JavaScriptはSchemeに非常に近い強力な動的言語であるため、RubyまたはLISPは意味がありません。
最後に、複数の言語のDOM統合を実際にサポートしたいブラウザメーカーは何ですか？各実装には固有のバグがあります。 MS JavascriptとMozilla Javascriptの違いに対処するための火事をすでに経験してきましたが、今ではその痛みを5倍または6倍にしたいのですか？
意味がありません。
Windowsでは、Scripting Hostに他の言語を登録して、IEで使用できるようにすることができます。たとえば、VBScriptはそのまま使用できます（ただし、ほとんどの目的ではJavaScriptよりも悪いため、あまり人気がありません）。
Python win32拡張により、PythonにIEこのように簡単に追加できましたが、実際にはそうではありませんでしたが、 Pythonはサンドボックス化するのは非常に困難です。多くの言語機能は、おそらく制限されたアプリケーションがブレークアウトするのに十分な実装フックを公開します。
一般に、ブラウザのようなネットに面したアプリケーションに複雑さが増すほど、セキュリティ問題が発生する可能性が高くなるという問題があります。たくさんの新しい言語が確かにその説明に当てはまりますが、これらはまだ急速に開発されている新しい言語です。
JavaScriptは見苦しい言語ですが、機能の選択的なサブセットを慎重に使用し、適切なオブジェクトライブラリからサポートすることで、一般的にかなり許容できるようになります。 JavaScriptへのインクリメンタルで実用的な追加が、Webスクリプティングが進む唯一の方法であると思われます。
ブラウザーでは標準言語に依存しないVM（静的に型付けされた言語でコーディングすることを好みます）。
（技術的に）徐々に実行可能です：最初の1つの主要なブラウザーがこれをサポートし、サーバーは現在の要求が互換性のあるブラウザーからの場合はバイトコードを送信するか、コードをJavaScriptに変換してプレーンテキストJavaScriptを送信する可能性があります。
JavaScriptにコンパイルするいくつかの実験言語が既に存在しますが、定義されたVMがあると、パフォーマンスが向上する可能性があります）。
ただし、「標準」部分は非常に注意が必要です。また、ライブラリに関する言語機能（たとえば、静的タイピングと動的タイピング）の間で競合が発生します（新しいものが同じライブラリを使用すると仮定）。したがって、私はそれが起こるとは思わない（すぐに）。
手を汚しているように感じたら、洗脳されているか、「DHTML年」の後遺症をまだ感じています。 JavaScriptは非常に強力で、その目的に適しています。クライアント側の対話性をスクリプト化することです。これが、JavaScript 2.0がこんなにひどいラップを得た理由です。つまり、パッケージ、インターフェイス、クラスなどがサーバーサイド言語の明確な側面であるのに、なぜだろうか。 JavaScriptは、本格的なオブジェクト指向ではなく、プロトタイプベースの言語としては問題ありません。
サーバー側とクライアント側がうまく通信していないためにアプリケーションにシームレス性がない場合は、アプリケーションの設計方法を再検討する必要があります。私は非常に堅牢なWebサイトとWebアプリケーションを使用してきましたが、一度も言ったことは一度もありません。それが可能であれば、JavaScriptではなく、ActionScript、AIR、またはSilverlightになります。私はそれを必要とせず、ほとんどの開発者も必要としません。これらはニースのテクノロジーですが、解決策ではなく、テクノロジーで問題を解決しようとします。
標準のウェブVMは考えられないと思います。使用する任意のVMバイトコード形式を迅速に逆コンパイルできることを保証する限り、新しいWeb VM標準を優雅に完全なレガシーサポートで導入できる方法がいくつかあります。 javascript、および結果の出力が合理的に効率的であること（スマートデコンパイラーがおそらく人間が自分で生成できるjavascriptよりも優れたjavascriptを生成すると推測するまでです）。
このプロパティを使用すると、任意のWeb VM形式をサーバー（高速）、クライアント（低速ですが、サーバーの制御が制限されている場合に可能）で簡単に逆コンパイルできます。 -新しい標準をネイティブにサポートしていないブラウザの場合、クライアントまたはサーバー（最速）によって動的に生成およびロードされます。
新しい標準をネイティブでサポートするブラウザは、web vmベースのアプリのランタイムの高速化の恩恵を受けるでしょう。さらに、ブラウザがレガシーのJavaScriptエンジンをWeb VM標準に基づいている（つまり、JavaScriptをWeb VM標準に解析してから実行する）場合、2つのランタイムを管理する必要はありませんが、それはブラウザのベンダー次第です。
Javascriptは、ページを直接制御できる唯一の十分にサポートされているスクリプト言語ですが、Flashには、より大きなプログラム用の非常に優れた機能がいくつかあります。最近はJITを備えており、オンザフライでバイトコードを生成することもできます（フラッシュを使用してユーザー入力の数式をネイティブバイナリにコンパイルする例については、 ランタイム式評価 をご覧ください）。 Haxe言語は、推論とバイトコード生成機能を備えた静的型付けを提供し、選択したほぼすべてのランタイムシステムを実装できます。
この質問は定期的に再浮上しています。これに対する私のスタンスは：
A）起こりませんおよびB）はすでにここにあります。
ごめん、何？説明させてください：
広告A
a VMは単なる汎用魔法デバイスではありません。ほとんどのVMは特定の言語および特定の言語機能に最適化されています。JRE/ Java（またはLLVM）を使用します。動的な型指定などを実装する際には、間違いなく問題と欠点がありますJavaはそもそもサポートしていませんでした。
そのため、多くの言語機能（テールコールの最適化、静的および動的タイピング、foo bar boo、...）をサポートする「汎用多目的VM」は、巨大で、実装が難しく、おそらく最適化するのが最適化が難しいでしょうそれ。しかし、私は言語デザイナーやvmの達人ではありません。多分間違っています。実際には非常に簡単で、まだ誰もアイデアを持っていません。 hrm、hrm。
広告B
すでにここにあります：バイトコードコンパイラ/ vmはないかもしれませんが、実際には必要ありません。 afaik javascriptは完全に調整されているため、次のいずれかが可能です。
- 言語Xからjavascript（例：coffeescript）に翻訳者を作成します
- 言語Xを解釈するJavaScriptでインタープリターを作成します（例 brainfuck ）。はい、パフォーマンスはひどいですが、ちょっと、すべてを持つことはできません。
広告C
何？そもそもポイントCはありませんでした！？まだないからです。 google NACL。誰でもできるならグーグルだ。 Googleが機能するようになると、問題は解決します。ただ、ええ、それは決して機能しないかもしれません、私は知りません。最後にそれについて読んだとき、本当にトリッキーな種類の未解決のセキュリティ問題がいくつかありました。
それとは別に：
javascriptは〜1995 = 15年以来存在しています。それでも、今日のブラウザの実装は異なります（少なくとも、それはもはや耐え難いものではありませんが）。そのため、まだ何か新しいことを始めた場合、2035年頃にクロスブラウザで動作するバージョンを使用できます。少なくとも動作するサブセット。それは微妙に異なるだけです。互換性ライブラリとレイヤーが必要です。しかし、物事を改善しようとしないことは意味がありません。
また、読みやすいソースコードはどうですか？多くの企業が、コードを「種類のない」オープンソースとして提供したくないことを知っています。個人的には、怪しい何かを疑ったり、そこから学びたいと思ったら、ソースを読むことができてとても幸せです。ソースコードの完全版！
この古い質問のクイックアップデート。
「WebページにはJavaScriptなどの高レベル言語ではなくバイトコードが含まれる」と断言したすべての人は「起こらない」。
2015年6月 W3C 発表 WebAssembly つまり
ウェブへのコンパイルに適した、サイズが大きく、読み込み時間の効率的な新しいポータブル形式。
これはまだ実験的ですが、Firefoxにはすでに夜間にプロトタイプの実装がいくつかあり、Chrome Canaryがあり、すでに デモが機能しています があります。
現在、WebAssemblyは主にC/C++から生成されるように設計されていますが、
WebAssemblyが進化するにつれて、C/C++よりも多くの言語をサポートするようになり、他のコンパイラも同様にサポートすることを期待しています 。
プロジェクトの 公式ページ を詳しく見てみましょう。本当にエキサイティングです！
あなたの推論にいくつかのエラーがあります。
標準ブラウザの標準仮想マシンは決して標準ではありません。ブラウザは4つあり、IEは「標準」に関して利益相反があります。他の3つは急速に進化していますが、新しいテクノロジーの採用率は遅いです。携帯電話、小型デバイス、 ...
さまざまなブラウザーとその過去の履歴にJSを統合すると、JSのパワーを過小評価することになります。あなたは標準を誓いますが、初期には標準がうまくいかなかったためJSを承認しません。
他の人が言ったように、JSはAIR/.NET/...などとは異なります。現在の化身のJSは、その目標に完全に適合しています。
長期的には、PerlとRubyはjavascriptに取って代わることができます。しかし、これらの言語の採用は遅く、JSを引き継ぐことはありません。
確かに。 Silverlightは事実上、クライアント側の.NetベースのVMです。
どのように最適に定義しますか？ブラウザに最適ですか、それとも開発者に最適ですか？ （プラスECMAScriptはJavascriptとは異なりますが、それは技術的です。）
JavaScriptは同時に強力でエレガントであることがわかります。残念ながら、私が会ったほとんどの開発者は、実際のプログラミング言語ではなく、必要な悪のように扱っています。
私が楽しんでいる機能のいくつかは次のとおりです。
- 機能をファーストクラスの市民として扱う
- いつでも任意のオブジェクトに関数を追加および削除できる（あまり役に立たないが、気がついたら気をつけて）
- それは動的言語です。
対処するのは楽しいですし、確立されています。クライアントスクリプティングにとって「最良」ではないかもしれないが、それは確かに楽しいからです。
ブラウザーの非互換性のために動的ページを作成するのはイライラすることですが、それはUIライブラリーによって軽減できます。 SwingをJavaに対して保持するよりも、JavaScript自体に対して保持する必要はありません。
JavaScriptは、ブラウザの標準仮想マシンです。たとえば、OCamlとHaskellの両方には、JavaScriptを出力できるコンパイラがあります。制限はJavaScript言語ではなく、JavaScriptを介してアクセス可能なブラウザーオブジェクト、およびマシンを危険にさらすことなくJavaScriptを安全に実行できるようにするために使用されるアクセス制御モデルです。現在のアクセス制御は非常に貧弱であるため、JavaScriptは安全上の理由からブラウザオブジェクトへの非常に限られたアクセスしか許可されていません。 Harmonyプロジェクトはそれを修正しようとしています。
それはクールなアイデアです。さらに一歩進んでみませんか？
- 同じVM言語でHTMLパーサーとレイアウトエンジン（実際にはブラウザーのすべての複雑なビット）を記述します。
- エンジンをWebに公開する
- 使用するレイアウトエンジンとそのURLの宣言を含むページを提供する
次に、すべてのクライアントに新しいブラウザをプッシュする必要なく、ブラウザに機能を追加できます。関連する新しいビットはWebから動的にロードされます。また、ブラウザで動作するすべてのものとの後方互換性を維持するというとんでもない複雑さなしに、HTMLの新しいバージョンを公開することもできます。互換性はページ作成者の責任です。また、HTML以外のマークアップ言語を試すこともできます。そしてもちろん、私たちはあなたが好きな言語であなたのウェブページをスクリプト化できるように、エンジンに素晴らしいJITコンパイラを書くことができます。
可能なスクリプト言語としてjavascript以外の言語を歓迎します。
クールなのは、Javascript以外の言語を使用することです。 Javaはおそらくタグの間にあまり合いませんが、Haskell、Clojure、Scala、Ruby、Groovyのような言語は有益です。
私はしばらく前にクロスRubyscriptに来ました... http://almaer.com/blog/running-Ruby-in-the-browser-via-script-typetextruby and http：/ /code.google.com/p/Ruby-in-browser/
まだ実験的で進行中ですが、有望に見えます。
。Netの場合： http://www.silverlight.net/learn/dynamic-languages/ サイトを見つけたばかりですが、面白そうです。 Apple Mac からでも動作します。
Javascriptの代替を提供する上で上記の機能がどれほど優れているかはわかりませんが、一見するとかなりクールに見えます。これにより、ブラウザのサンドボックス内で、ブラウザからネイティブで任意のJavaまたは.Netフレームワークを使用できるようになります。
安全性に関しては、言語がJVM（またはその点で.Netエンジン）内で実行される場合、VMがセキュリティの面倒を見るので、それについて心配する必要はありません-少なくともブラウザー内で実行されるものについては必要ありません。
既にVBScriptがありますよね。待ってください、IEがサポートしています！
VMの素敵なアイデアと同じです。 Luaを使用してページのスクリプトを作成し、ブラウザにバイトコードに変換するパーサーがない場合はどうなりますか？もちろん、スクリプトタグがバイトコードのファイルを受け入れることを想像できますが、これは非常に効率的です。
しかし、Webに何か新しいものを持ち込むことは困難であるという経験から、このような抜本的な新しい変更を採用するには何年もかかるでしょう。 SVGまたはCSS3をサポートするブラウザーの数は？
それに、JSで「汚い」と思うものは見当たりません。アマチュアによってコーディングされ、他の場所にコピーされた悪い習慣を広めるとifいかもしれませんが、マスターはそれがエレガントな言語である可能性があることを示しました。 Perlに少し似ています：多くの場合、難読化された言語のように見えますが、完全に読みやすくすることができます。
これは非常に良い質問です。
JSだけの問題ではありません。JSでより大きなプログラムを開発するための優れた無料のIDEが不足しているからです。無料のEclipseのみを知っています。もう1つの優れた機能はMicrosoftのVisual Studioですが、無料ではありません。
なぜ無料なのでしょうか？ Webブラウザーベンダーがデスクトップアプリをオンラインアプリに置き換えたい（そして望む）場合、プログラマー、優れた開発ツールを提供する必要があります。シンプルなテキストエディター、JSLint、および組み込みのGoogle Chromeデバッガーを使用して50,000行のJavaScriptを作成することはできません。
Borlandが1987年にTurbo Pascal 4.0のIDEを作成したとき、それはプログラミングの革命でした。それから24年が経過しました。構文チェックと適切なデバッガー。おそらく、優れたIDEが非常に少ないためです。
Windows、Linux、MacOS、iOS、Symbianなどと戦うことができるアプリケーションを構築したい場合、プログラマ向けの適切な（無料）ツールを作成することは、Webブラウザベンダーの利益です。
これを確認してください http://www.visitmix.com/Labs/Gestalt/ -ユーザーがsilverlightをインストールしている限り、pythonまたはRubyを使用できます。
おそらく、しかしそうするためには、それらをサポートするために主要なブラウザを入手する必要があります。 IEサポートを取得するのは最も困難です。JavaScriptが使用可能であるとみなせる唯一のものであるため、JavaScriptが使用されます。
ECMAScriptなどについて話した開発者の大多数。 al。問題はスクリプト言語ではなく、それが公開するばかげたHTML DOMであると認めることになります。 DOMとスクリプト言語の統合は、ECMAScriptに関する一般的な苦痛とフラストレーションの原因です。また、忘れないでください、IISはサーバー側のスクリプトにJScriptを使用できます。Rhinoなどを使用すると、ECMAScriptで自立型アプリを構築できます。これらの環境のいずれかでECMAScriptを使用してみてくださいしばらくの間、あなたの意見が変わるかどうかを確認してください。
この種の絶望はしばらく前から続いています。これを編集して、特定の問題を含めたり、再投稿したりすることをお勧めします。あなたはあなたが得る安reliefのいくつかに快く驚かれるかもしれません。
古いサイトですが、まだ開始するのに最適な場所： Douglas Crockfordのサイト 。
現実的には、Javascriptはブラウザが長い間使用する唯一の言語であるため、他の言語を使用するのは非常に良いことですが、それが起こっていることはわかりません。
この「標準化されたVM」は非常に大きく、すべての主要なブラウザーで採用する必要があり、ほとんどのサイトは他の多くのブラウザーよりもWebサイトに適しているため、とにかくJavascriptの使用を続けます。
各プログラミング言語をこのVMでサンドボックス化し、各言語がシステムにアクセスする量を減らす必要があります。言語の多くの変更と多くの機能の削除または再実装が必要です。 Javascriptはすでにこれを念頭に置いており、長い間行ってきました。
たぶん、あなたはGoogleのネイティブクライアントを探しています。
ある意味では、Javaバイトコードのようなより一般的なものの代わりに、ブラウザでJavascriptのような表現力豊かな言語を持つことは、より開かれたWebを意味します。
それらはすべてバイトコードインタプリタを備えたVMをすでに持っているため、バイトコードもすべて異なります。 {Chakra（IE）、Firefox（SpiderMonkey）、Safari（SquirrelFish）、Opera（Carakan）。
申し訳ありませんが、Chrome（V8）はIA32マシンコードにコンパイルします。
あなたは「JavaScriptは現在私たちが取り組まなければならないものであるという現実的な問題を理解している」とは思いません。実際、それは非常に強力な言語です。何年もブラウザにJavaアプレットがありましたが、現在はどこにありますか？
とにかく、クライアントで作業するために「汚れる」必要はありません。たとえば、GWTを試してください。
... もしかして...
JavaおよびJavaアプレットFlashおよびAdobe AIRなど。
一般的に、どのRIAフレームワークでもニーズを満たすことができます。しかし、それを使用するために支払う代償があります（ej。ブラウザーで使用可能なランタイム、および/または純粋なデスクトップよりも少ないオプション） http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks
Web以外の言語でWebを開発するには、GWTが必要です。Javaを開発し、Javascriptにコンパイルします
これはそれほど簡単ではないの問題だと思います。私たちはJSにこだわっていると言えますが、jQuery、Prototype、scriptaculous、MooTools、およびすべての素晴らしいライブラリでは本当に悪いのでしょうか？
JSはlightweightであることを忘れないでください。V8、TraceMonkey、SquirrelFishを使用すると、最新のブラウザーで使用される新しいJavascriptエンジンがさらに重要になります。
また、proved-はい、問題があることはわかっていますが、初期のセキュリティ問題のように、これらの多くが整理されていますブラウザでRubyコードなどを実行できるようにするイメージング。セキュリティサンドボックスは一から作成する必要があります。そして、あなたは何を知っていますか？ Pythonすでに失敗 2回です。
Javascriptは、HTMLやCSSと同じように、時間の経過とともに改訂および改善になると思います。プロセスは長いかもしれませんが、この世界ではすべてが可能というわけではありません。