標準のブラウザ仮想マシンではなくJavaScriptを使用する理由

特別な言語（実際には特別なパラダイム）の使用を要求するのではなく、ブラウザーでホストされる標準化された仮想マシンを介して一連の言語（Java、Python、Rubyなど）をサポートすることは意味がありませんか？クライアントスクリプト専用ですか？

提案を明確にするために、WebページにはJavaScriptのような高水準言語の代わりにバイトコードが含まれます。

JavaScriptは進化論上の理由から、今私たちが取り組まなければならないものであるという実際的な現実を理解していますが、長期についてもっと考えています。下位互換性に関しては、インラインJavaScriptを一定期間同時にサポートできなかった理由はありません。もちろん、JavaScriptはブラウザー仮想マシンでサポートされている言語の1つである可能性があります。

はい、そうです。確かにタイムマシンがあったとしても、さかのぼって多くのJavascript機能が異なるように設計されていることを確認することは、大きな娯楽です（つまり、IEのCSSエンジンを設計した人がITに参加しないようにすること）。しかし、それは起こらないだろう、そして私たちは今それで立ち往生しています。

やがて、それはWebの「機械語」になり、他のよりよく設計された言語とAPIがそれにコンパイルされる（そして、さまざまなランタイムエンジンの可能性に対応する）と思います。

ただし、これらの「優れた設計言語」がJava、Python、Rubyになるとは思いません。JavaScriptは、他の場所で使用できるにもかかわらず、Webアプリケーションスクリプト言語です。そのユースケースを考えると、これらの言語のどれよりも優れたことができます。

JavaScriptは良い言語だと思いますが、クライアント側のWebアプリケーションを開発する際には選択肢が欲しいです。レガシーな理由でJavaScriptにこだわっていますが、そのシナリオの変更を模索しているプロジェクトやアイデアがあります。

1. Google Native Client：ブラウザでネイティブコードを実行するためのテクノロジー。
2. Emscripten：JavaScriptへのLLVMバイトコードコンパイラ。LLVM言語をブラウザーで実行できるようにします。
3. アイデア：ブラウザーの.NET CLI、Monoの作成者：http : //tirania.org/blog/archive/2010/May-03.html

私たちは長い間JavaScriptを使用すると思いますが、それは遅かれ早かれ変わるでしょう。ブラウザで他の言語を使用することをいとわないほど多くの開発者がいます。

答える質問 -いいえ、それは意味がありません。

現在、多言語VMに最も近いものは、JVMとCLRです。これらはまさに軽量な獣ではなく、このサイズと複雑さの何かをブラウザに埋め込んでみても意味がありません。

既存のソリューションよりも優れた新しい多言語VMを作成できると考えてみましょう。

• あなたは安定性に遅れをとっています。
• 複雑さに遅れをとっている（複数の言語で一般化しようとしているため、遅れをとっている）
• 採用が遅れています

だから、いいえ、それは意味がありません。

これらの言語をサポートするためには、APIを厳格に取り除き、ブラウザースクリプトのコンテキストで意味のない部分を切り取らなければならないことを覚えておいてください。ここでは多数の設計上の決定が行われ、エラーの大きな機会があります。

機能の面では、とにかく本当に DOMでのみ作業しているので、これは実際には構文と言語のidomの問題であり、その時点で「これは本当に価値があるのか​​？」

念頭に置いては、のみ、サーバー側のスクリプトは、あなたが好きな言語ですでに提供されていますので、我々が話している事は、クライアント側のスクリプトです。これは比較的小さなプログラミング分野であるため、複数の言語を導入するメリットには疑問があります。

どんな言語を取り入れたら意味があるのでしょうか？（警告、主観的な資料が続きます）

Cのような言語を使用することは、metalで作業するために作成されているため意味がありません。また、ブラウザーでは、実際に使用できるmetalは多くありません。

Javaのような言語を導入することは、とにかくAPIが最良であるため、意味がありません。

JavaScriptはSchemeに非常に近い強力な動的言語であるため、RubyやLispなどの言語を使用しても意味がありません。

最後に、どのブラウザメーカーが実際に複数言語のDOM統合をサポートしたいですか？各実装には、固有のバグがあります。MS JavascriptとMozilla Javascriptの違いに対処する火事についてはすでに説明してきましたが、今ではその痛みを5倍から6倍に増やしたいと思いますか？

それは意味がありません。

Windowsでは、スクリプトホストに他の言語を登録して、IEで使用できるようにすることができます。たとえば、VBScriptはそのままの状態でサポートされます（ただし、ほとんどの目的でJavaScriptよりも悪いため、あまり人気を得ていません）。

Python win32拡張機能を使用すると、このように簡単にPythonをIEに追加できますが、Pythonをサンドボックス化するのは非常に難しいため、あまり良いアイデアではありませんでした。多くの言語機能は、制限されていると思われるアプリケーションがブレークアウトするのに十分な実装フックを公開しています。

一般に問題は、ブラウザのようなネットに面するアプリケーションに追加する複雑さが増すほど、セキュリティの問題が発生する可能性が高くなることです。新しい言語の束は確かにその説明に適合し、これらはまだ急速に発展している新しい言語です。

JavaScriptは醜い言語ですが、機能の選択的なサブセットを注意深く使用し、適切なオブジェクトライブラリからサポートすることにより、JavaScriptは一般にかなり許容できるものになります。JavaScriptへの漸進的で実用的な追加は、Webスクリプトが先に進む可能性が高い唯一の方法のようです。

私はブラウザーで標準の言語に依存しないVMを間違いなく歓迎します（静的に型付けされた言語でコーディングすることを好みます）。

（技術的に）徐々に実行可能になりました：最初の1つの主要ブラウザーがサポートし、サーバーは現在の要求が互換性のあるブラウザーからのものである場合はバイトコードを送信するか、コードをJavaScriptに変換してプレーンテキストのJavaScriptを送信する可能性があります。

JavaScriptにコンパイルする実験的な言語はすでにいくつか存在しますが、VMを定義すると（おそらく）パフォーマンスが向上します。

ただし、「標準」の部分はかなり扱いにくいものです。また、ライブラリに関する言語機能（静的型と動的型の比較など）の間で競合が発生します（新しいものが同じライブラリを使用すると想定）。したがって、それは（すぐに）起こるとは思わない。

手を汚しているように感じる場合は、洗脳されているか、「DHTMLの時代」の影響をまだ感じています。JavaScriptは非常に強力であり、その目的（対話機能のクライアント側をスクリプト化すること）に適しています。これが、JavaScript 2.0がこのような悪いラップをした理由です。つまり、パッケージ、インターフェース、クラスなどがサーバー側言語の側面であるのはなぜか。JavaScriptは、本格的なオブジェクト指向ではなく、プロトタイプベースの言語としては問題ありません。

サーバー側とクライアント側がうまく通信していないためにアプリケーションにシームレス性が欠けている場合は、アプリケーションの設計方法を再検討することをお勧めします。私は非常に堅牢なWebサイトとWebアプリケーションを扱ってきましたが、「うーん、JavaScriptが本当に（xyz）にできたらいいのに」と言ったことは一度もありません。それが可能であれば、それはJavaScriptではなく、ActionScript、AIR、またはSilverlightです。私はそれを必要としませんし、ほとんどの開発者も必要としません。これらは優れたテクノロジーですが、テクノロジーでは問題を解決しようとします。解決策ではありません。

標準のWeb VMが考えられないほどだとは思いません。使用するVMバイトコード形式をすばやくJavaScriptに逆コンパイルでき、結果の出力がかなり効率的になることを保証する限り、新しいWeb VM標準を優雅に、完全にレガシーサポートで導入する方法はいくつかあります（私は、スマートデコンパイラーがおそらく人間が自分で作成することのできるjavascriptよりも優れたjavascriptを生成することになるとさえ考えています。

このプロパティを使用すると、任意のWeb VM形式をサーバー（高速）、クライアント（低速ですが、サーバーの制御が制限されている場合は可能）で簡単に逆コンパイルするか、事前に生成して動的に読み込むことができます。新しい標準をネイティブにサポートしていないブラウザーの場合は、クライアントまたはサーバー（最速）。

新しい標準をネイティブでサポートするブラウザーは、Web VMベースのアプリのランタイムの速度を上げることでメリットを得られます。その上、ブラウザーがレガシーJavaScriptエンジンをWeb VM標準に基づいている場合（つまり、JavaScriptをWeb VM標準に解析して実行する場合）、2つのランタイムを管理する必要はありませんが、それはブラウザーのベンダー次第です。 。

JavaScriptは、ページを直接制御できる、十分にサポートされている唯一のスクリプト言語ですが、Flashには、より大きなプログラム用の非常に優れた機能がいくつかあります。最近はJITを備えており、バイトコードを即座に生成することもできます（フラッシュを使用してユーザー入力の数式をネイティブバイナリにコンパイルする例については、ランタイム式の評価を確認してください）。Haxe言語は、推論による静的型付けと、選択したほぼすべてのランタイムシステムを実装できるバイトコード生成機能を提供します。

この古い質問のクイックアップデート。

「JavaScriptのような高レベルの言語ではなくバイトコードがWebページに含まれる」ことを「誰も起こらない」と断言したすべての人。

2015年6月、W3CはWebAssemblyを発表しました。

Webへのコンパイルに適した、サイズとロード時間の効率に優れた新しいポータブルフォーマット。

これはまだ実験段階ですが、FirefoxナイトリーとChrome Canaryにはすでにいくつかのプロトタイプ実装があり、すでにいくつかのデモが機能しています。

現在、WebAssemblyは主にC / C ++から生成されるように設計されていますが、

WebAssemblyが進化するにつれ、C / C ++よりも多くの言語がサポートされるようになり、他のコンパイラーもサポートすることを期待しています。

プロジェクトの公式ページを詳しく見てみましょう。本当にエキサイティングです！

この質問は定期的に再確認されます。これに対する私のスタンスは：

A）が起こる文句を言わないと、B）はすでにここにあります。

何を？説明させてください：

広告A

VMは、ある種の普遍的な魔法のデバイスではありません。ほとんどのVMは、特定の言語および特定の言語機能用に最適化されています。JRE / Java（またはLLVM）を使用してください。静的型付けに最適化されています。動的型付けやJavaがそもそもサポートしていなかった他のものを実装する際には、明らかに問題と欠点があります。

したがって、多くの言語機能（末尾呼び出しの最適化、静的および動的型付け、foo bar booなど）をサポートする「汎用多目的VM」は、巨大で、実装が困難であり、最適化して優れたパフォーマンスを得るのがおそらく難しいでしょう。それ。しかし、私は言語デザイナーやvmの第一人者ではありません。多分私は間違っています。実際には非常に簡単ですが、まだ誰もアイデアを持っていませんか？hrm、hrm。

広告B

すでにここにあります：バイトコードコンパイラ/ vmはないかもしれませんが、実際には必要ありません。afaik javascriptは完全に準備中なので、次のいずれかが可能になるはずです。

1. 言語Xからjavascript（たとえばcoffeescript）へのトランスレータを作成する
2. 言語Xを解釈するJavaScriptでインタープリターを作成します（例：brainfuck）。はい、パフォーマンスはひどいですが、ねえ、すべてを持つことはできません。

ad C

何？そもそもポイントCがなかった！？まだないので... google NACL。誰かがそれを行うことができれば、それはグーグルです。グーグルがそれを機能させるとすぐに、あなたの問題は解決されます。ただ、ええと、それは決して機能しないかもしれません、私は知りません。最後にそれを読んだとき、本当にトリッキーな種類のいくつかの未解決のセキュリティ問題がありました。

それとは別に：

• javascriptは〜1995 = 15年以来存在しています。それでも、ブラウザーの実装は今日異なります（少なくとも、それはもう十分ではありません）。そのため、まだ何か新しいものを開始する場合、2035年頃にクロスブラウザーで動作するバージョンがある可能性があります。少なくとも動作するサブセット。それは微妙に異なるだけです。互換性のあるライブラリとレイヤーが必要です。物事を改善しようとしても意味がありません。

• また、読みやすいソースコードはどうですか？私は多くの企業が彼らのコードを「一種の」オープンソースとして提供したくないことを知っています。個人的には、何か怪しいと思われる場合や、そこから学びたい場合は、ソースを読むことができてとてもうれしいです。ソースコードのフーレイ！

確かに。Silverlightは事実上、まさにクライアント側の.NetベースのVMです。

あなたの推論にはいくつかのエラーがあります。

1. 標準ブラウザの標準仮想マシンが標準になることはありません。私たちには4つのブラウザがあり、IEは「標準」に関して利害が対立しています。他の3つは急速に進化していますが、新しいテクノロジーの採用率は遅いです。電話、小型デバイスのブラウザについてはどうですか？

2. さまざまなブラウザーでのJSの統合とその過去の履歴により、JSのパワーが過小評価されます。あなたは標準を誓約しましたが、初期の段階では標準がうまくいかなかったため、JSを承認しません。

3. 他の人が言うように、JSはAIR / .NET / ...などと同じではありません。現在の化身のJSは、その目標に完全に適合しています。

長期的には、PerlとRubyはjavascriptに取って代わることができます。しかし、それらの言語の採用は遅く、JSを引き継ぐことは決してないことが知られています。

どのように最もよく定義しますか？ブラウザに最適ですか、それとも開発者に最適ですか？（さらにECMAScriptはJavascriptとは異なりますが、それは専門性です。）

JavaScriptは、同時に強力でエレガントであることがわかります。残念ながら、私が会ったほとんどの開発者は、実際のプログラミング言語ではなく、必要な悪のように扱います。

私が楽しむ機能のいくつかは次のとおりです。

• ファーストクラスの市民として機能を扱う
• 任意のオブジェクトにいつでも関数を追加および削除できること（あまり役に立たないが、気になる場合は注意）
• それは動的言語です。

対処するのは楽しいですし、確立されています。クライアントスクリプトに「最適」ではないかもしれませんが、それは確かに楽しいので、周りにいる間は楽しんでください。

ブラウザーの非互換性のために動的ページを作成するときにイライラすることには同意しますが、UIライブラリによって軽減できる場合があります。これは、SwingがJavaに対して保持されるべきである以上、JavaScript自体に対して保持されるべきではありません。

JavaScriptはブラウザの標準仮想マシンです。たとえば、OCamlとHaskellの両方に、JavaScriptを出力できるコンパイラが追加されました。制限はJavaScriptの言語ではなく、JavaScriptを介してアクセス可能なブラウザーオブジェクト、およびマシンを危険にさらすことなくJavaScriptを安全に実行できるようにするために使用されるアクセス制御モデルです。現在のアクセス制御は非常に貧弱であり、JavaScriptは安全上の理由からブラウザオブジェクトへの非常に限られたアクセスしか許可されていません。Harmonyプロジェクトはそれを修正しようとしています。

それはクールなアイデアです。さらに一歩進んでみませんか？

• HTMLパーサーとレイアウトエンジン（ブラウザーのすべての複雑なビット）を同じVM言語で作成する
• エンジンをウェブに公開する
• 使用するレイアウトエンジンとその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とhttp://code.google.com/p/ruby-ブラウザ内/
まだ実験的で進行中ですが、有望に見えます。
.Netの場合：http ://www.silverlight.net/learn/dynamic-languages/ サイトを見つけたばかりですが、面白そうです。私のApple Macからでも動作します。

上記がJavaScriptの代替手段を提供する上でどれほど優れているかはわかりませんが、一見するとかなりクールに見えます。潜在的に、これにより、ブラウザのサンドボックス内で、ブラウザからJavaまたは.Netフレームワークをネイティブに使用できるようになります。

安全性に関しては、言語がJVM（またはそのことについては.Netエンジン）内で実行される場合、VMがセキュリティを処理するので、それについて心配する必要はありません。ブラウザ内。

おそらく、そうするためには、主要なブラウザーがそれらをサポートするようにする必要があります。IEのサポートは入手が最も難しいでしょう。JavaScriptを使用できるのは、JavaScriptを使用できることが唯一の理由であるためです。

ECMAScript etについて私が話し合った開発者の大多数。al。問題がスクリプト言語ではないことを認めてしまうのは、それが公開しているとんでもないHTML DOMだからです。DOMとスクリプト言語の融合は、ECMAScriptに関する苦痛と不満の一般的な原因です。また、IISはサーバーサイドスクリプティングにJScriptを使用できます。Rhinoなどの機能により、ECMAScriptで独立型アプリを構築できます。これらの環境のいずれかでECMAScriptをしばらく試してみて、意見が変わるかどうかを確認してください。

この種の絶望はしばらく前から続いています。これを編集して、特定の問題を含めたり、再投稿したりすることをお勧めします。あなたが得る救済のいくつかにうれしい驚きがあるかもしれません。

古いサイトですが、まだ始めるのに最適な場所です：ダグラス・クロックフォードのサイト。

ええと、VBScriptは既にありますね。待って、IEだけがそれをサポートしています！
VMの良いアイデアについても同じです。Luaを使用して自分のページをスクリプト化し、ブラウザーにページをバイトコードに変換するパーサーがない場合はどうなりますか？もちろん、スクリプトタグがバイトコードのファイルを受け入れることも想像できますが、これは非常に効率的です。
しかし経験から、Webに新しいものをもたらすのは難しいことがわかります。このような抜本的な新しい変更を採用するには、何年もかかるでしょう。SVGまたはCSS3をサポートするブラウザーはいくつありますか？

加えて、私はあなたがJSで「汚い」と思うものを見ません。アマチュアによってコーディングされ、他の場所にコピーされた悪い習慣を広めると、それは醜いかもしれませんが、マスターはそれがエレガントな言語にもなり得ることを示しました。Perlに少し似ています。多くの場合、難読化された言語のように見えますが、完全に読み取り可能にすることができます。

これをhttp://www.visitmix.com/Labs/Gestalt/で確認してください。ユーザーがSilverlightをインストールしている限り、PythonまたはRubyを使用できます。

これは非常に良い質問です。

これはJSだけの問題ではなく、JSでより大きなプログラムを開発するための優れた無料のIDEがないためです。私が知っているのは無料のEclipseだけです。もう1つはMicrosoftのVisual Studioですが、無料ではありません。

なぜ無料なのですか？Webブラウザーベンダーがデスクトップアプリをオンラインアプリに置き換えたい（そして望んでいる）場合は、プログラマーや優れた開発ツールを提供する必要があります。シンプルなテキストエディター、JSLint、および組み込みのGoogle Chromeデバッガーを使用して50,000行のJavaScriptを作成することはできません。あなたがmacohistでない限り。

ボーランドが1987年にターボパスカル4.0のIDEを作成したとき、それはプログラミングの革命でした。あれから24年。残念なことに、2011年には、多くのプログラマーはまだコード補完、構文チェック、適切なデバッガーを使用していません。おそらく良いIDEが非常に少ないからでしょう。

プログラマーがWindows、Linux、MacOS、iOS、Symbianなどと戦うことができるアプリケーションを構築したい場合、適切な（無料の）ツールを作成することがWebブラウザーベンダーの利益になります。

現実的には、どのブラウザでも長い間Javascriptが使用される唯一の言語であるため、他の言語を使用することは非常に良いことですが、それが起こるのを見ることができません。

あなたが話しているこの「標準化されたVM」は非常に大きく、すべての主要なブラウザーで採用する必要があります。ほとんどのサイトは、他の多くのブラウザーよりもWebサイトに適しているため、とにかくJavascriptを使い続けるでしょう。

このVMの各プログラミング言語をサンドボックス化し、システムへの各言語のアクセス量を減らす必要があるため、言語の大幅な変更と、多くの機能の削除または再実装が必要になります。JavaScriptはすでにこのことを念頭に置いており、長い間行われてきました。

Googleのネイティブクライアントを探しているのかもしれません。

ある意味で、Javaバイトコードのようなより一般的なものの代わりに、ブラウザにJavaScriptのようなより表現力のある言語を使用することは、よりオープンなWebを意味しました。

これはそれほど簡単な問題ではないと思います。JSに悩まされていると言えますが、jQuery、Prototype、scriptaculous、MooTools、その他すべての素晴らしいライブラリでは本当に悪いのでしょうか。

JSは軽量であることに注意してください。V8、TraceMonkey、SquirrelFish-最新のブラウザーで使用される新しいJavascriptエンジンを使用すると、さらに軽量になります。

それも証明されています -そうです、問題があることはわかっていますが、初期のセキュリティ問題のように、これらの問題の多くが整理されています。ブラウザーでRubyコードなどを実行できるようにするイメージング。セキュリティサンドボックスは、最初から実行する必要があります。そして、あなたは何を知っていますか？Pythonの人々はすでに2回失敗しています。

HTMLやCSSと同じように、Javascriptも時間の経過とともに改訂および改善されると思います。プロセスは長いかもしれませんが、この世界ですべてが可能であるとは限りません。

「JavaScriptが私たちが今取り組まなければならないものであるという実際的な問題を理解している」とは思わないでしょう。実際、それは非常に強力な言語です。あなたは何年もの間Javaアプレットをブラウザで使っていましたが、今どこにありますか？

とにかく、クライアントで作業するために「汚れる」必要はありません。たとえば、GWTを試してください。

... もしかして...

JavaおよびJavaアプレットFlashおよびAdobe AIRなど。

一般に、どのRIAフレームワークでもニーズを満たすことができます。しかし、誰にとってもそれを使用するために支払う代償があります（例えば、ブラウザーで実行可能なランタイムまたは/および専用または/および純粋なデスクトップよりも少ないオプション） http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Web以外の言語でWebを開発するには、GWTを使用します。Javaを開発し、Javascriptにコンパイルします。

それらにはすべて、バイトコードインタープリターを備えたVMがすでにあり、バイトコードもすべて異なるためです。{Chakra（IE）、Firefox（SpiderMonkey）、Safari（SquirrelFish）、Opera（Carakan）。

Chrome（V8）はIA32マシンコードにコンパイルできると思います。

まあ、すべてのブラウザーがすでにVMを使用していることを考えると、Web用のVM言語を作成することはそれほど難しくないと思います。
：私はそれはいくつかの理由のために大いに役立つだろうと思う
1.サーバーがコードをコンパイルするので、データて送信量が小さくなると、クライアントは、コードをコンパイルするには、腰の時間がありません。
2.サーバーはコードを準備してコンパイルして格納できるので、JSをすばやくコンパイルして少し時間を節約しようとするクライアントとは異なり、コードをより最適化できます。
3.言語をバイトコードにコンパイルする方が、JSにトランスパイルするよりもはるかに簡単です。

最後のメモとして（誰かがすでに別のコメントで言ったように）、HTMLとCSSはより単純な言語にコンパイルされます。バイトコードとしてカウントされるかどうかはわかりませんが、コンパイルされたhtmlとcssをサーバーからクライアントに送信することもできます。解析時間とフェッチ時間を短縮する

IMO、JavaScript、言語は問題ではありません。JavaScriptは実際には非常に表現力があり強力な言語です。古典的なOO機能がないので、それは悪い担当者になると思いますが、私にとっては、プロトタイプのグルーブを使うほど、好きになります。

私が見るところの問題は、ウェブでサポートすることを余儀なくされている多くのブラウザーでの不安定で一貫性のない実装です。jQueryのようなJavaScriptライブラリーは、その汚い感覚を軽減するのに大いに役立ちます。