Design: WebasmはブラウザのJavascriptを置き換えることができますか？

私はc＃に精通していませんが、実際には、wasmがjavascriptを完全に引き継ぐことはできないと思います。

まず、試した場合、JavaScriptから呼び出すときのわずかなオーバーヘッドのため、「+、-、*、/」やその他の数学関連の操作など、一部の低レベルの操作ではjavascriptがwasmよりもはるかに高速であることがわかります。 WebAssemblyに戻ってください。 ＃1120

第二に、Web開発者にとって、彼らはすでにjavascriptとその文法に精通しており、Web以外の別の開発言語でWebアプリを構築する必要はなく困難です。

最後に、「 Binary AST 」の助けを借りて、現在のWebアプリケーションのパフォーマンスは、それらのアプリケーションを変更することなく、新しいレベルに引き上げられます。

PS：
C＃またはJavaに関係なく、このプログラミング言語を開発者にとってはるかに使いやすいものにしたい場合は、「ウィークタイプ」などの「使いやすい」機能やその他の機能のために、この言語の効率が制限されます。

@Becavalier JSコンテキストオーバーヘッドからwasm関数を呼び出そうとしている場合は「はい」となる可能性がありますが、DOMクエリ/操作、CSSインライン、Canvasペイントなど、排他的に必要な場合を除いて、ランタイムはJavascriptと通信しません。 _etc .._ wasmコンテキスト内で行われるすべての実行はかなり高速です。 JSブリッジが導入されると、遅延が明らかになります。たとえば、＃1120の場合、追加の遅延であるwasmコンテキストで実行される関数のパフォーマンスタイムスタンプをJavascriptコンテキストで出力しようとしています。

Typescriptを採用した完全な改良版であるAngular2 / 4、KotlinのAndroid、SwiftのiOSなどの人気のあるフレームワークは、一部のフレームワークや言語の背後に大きな名前がある場合、世界中で変更を採用しようとします。

つまり、要点は、APIブリッジを抽象化し、ブラウザーにランタイムを移植することで、JSが除外されたり、画像から削除されたりする可能性があるということです。 Webassemblyは、他の言語のコンパイラーがブラウザー上のJavascriptと競合するための扉を開きました。

以前は、JSコードをV8などのVMでより効率的に実行できるようにするテクノロジーを採用していましたが、今ではJSコードを飛躍させることができるアセンブリコードを記述してコンパイルできます。

これで、TypeScript、CoffeeScriptなどのトランスパイラーに代わるWeb用のコンパイラーが期待できます。

Javascript開発者は、指を交差させてください。 今後数年間で大きな動きが期待できます。

PS：私はJavascriptとC-Langが大好きです

Webassemblyは、他の言語のコンパイラーがブラウザー上のJavascriptと競合するための扉を開きました。

はい、確かに、それはWebAssemblyの目的の1つです。

これがWebAssemblyFAQからの引用です：

WebAssemblyは、時間の経過とともに多くの言語をWebにコンパイルできるようになりますが、JavaScriptには信じられないほどの勢いがあり、Webの単一の特権（上記のとおり）動的言語のままです。 さらに、JavaScriptとWebAssemblyは、いくつかの構成で一緒に使用されることが期待されています。

• JavaScriptを活用して物事を結び付けるコンパイル済みC ++アプリ全体。

他の言語は何年もの間JavaScriptにコンパイルされており、WebAssemblyの有無にかかわらず

すでにC＃、F＃、C ++、OCaml、Elm、PureScript、Haskell、Java、Python、Ruby、PerlなどをJavaScriptにコンパイルできます。

.NETバイトコードをJavaScriptにコンパイルしたり、OCamlバイトコードをJavaScriptにGWTは11年前から存在しており、大規模なプロジェクトで使用されています。

これらのプロジェクトは何年も前から存在しています。 それは本当に新しいことではありません。

JavaScriptはすでに他の言語と競合しています。 WebAssemblyは、他の言語をより効率的にするだけです。それだけです。

以前は、JSコードをV8などのVMでより効率的に実行できるようにするテクノロジーを採用していましたが、今ではJSコードを飛躍させることができるアセンブリコードを記述してコンパイルできます。

はい。JavaScriptVMは、JITエンジンのオーバーヘッド（およびJavaScriptの本質的に動的な性質）のためにネイティブパフォーマンスを達成できないため、パフォーマンスを向上させるには、コード実行を厳密に低レベルで制御する必要があります。 WebAssemblyはあなたにそのコントロールを提供します。

つまり、要点は、APIブリッジを抽象化し、ブラウザーにランタイムを移植することで、JSが除外されたり、画像から削除されたりする可能性があるということです。

いいえ、人々は引き続きJavaScriptを使用します。

何年もの間、デスクトップには、Python、Perl、Ruby、PHP、Haskell、JavaScript（Node.js）、OCaml、C ++、Javaなどから選択できる多くの言語がありました。

人々はJavaScriptを含む多くの言語を使用しています。 JavaScriptはどこにも行きません。

JavaScriptが一流の言語ではない（非常にありそうもない）架空の世界でも、人々はJavaScriptをWebAssemblyにコンパイルすることができます。

これで、TypeScript、CoffeeScriptなどのトランスパイラーに代わるWeb用のコンパイラーが期待できます。

それはありそうにありませんが、人々がTypeScriptとJavaScriptを使用する正当な理由がまだあります。

もちろんそこに活字体の代替となり、一部の人々は、これらの選択肢を使用しますが、活字体は離れて行くことはほとんどありません。

TypeScriptの優れた代替手段（ Haxeなど）はすでに何年も前から存在していましたが、TypeScriptに取って代わることはなかったからです。

午前3時42時2017年9月4日には、Pauan [email protected]は書きました：
>>

JavaScriptはすでに他の言語と競合しています。 WebAssemblyはただ作る
他の言語の方が効率的です、それだけです。

後者は完全に正しくありません。 Wasmのもう1つの目標は、機能を有効にすることです
JavaScriptでサポートされていないため、サポートされない可能性があります。 にとって
たとえば、同時実行、末尾呼び出し、または再開可能な例外はすべて
ロードマップ。

@ rossberg-chromium確かにあなたは正しいです、私はその詳細を忘れていました。 明確にしていただきありがとうございます。

@Pauan詳細をありがとう。 あなたの主張のいくつかは有効で理にかなっていますが、私はすべてに同意しません。

クライアント側のC＃は、開発段階でJavascriptを完全に回避するための有望でキラーな例に見え

すでにC＃、F＃、C ++、OCaml、Elm、PureScript、Haskell、Java、Python、Ruby、PerlなどをJavaScriptにコンパイルできます。

はい、Javascriptが写真に写っていました。 しかし、 WASM / Webasmを使用すると、Javascriptにコンパイルする動機が変わります。 wasmに直接コンパイルし、必要に応じてJavascriptでAPIマスクレイヤーまたはブリッジを作成できるため、開発者ベースはWebappでWebアプリケーションを開発するためにJavascriptを知る必要はありません。つまり、ASP.netではなく純粋なWebapp、JSPのようなフレームワークです。

他の言語は何年もの間JavaScriptにコンパイルされており、WebAssemblyの有無にかかわらずコンパイルを続けることを覚えておいてください。

すでにC＃、F＃、C ++、OCaml、Elm、PureScript、Haskell、Java、Python、Ruby、PerlなどをJavaScriptにコンパイルできます。

多くの言語はすでにJavaScriptにコンパイルできますが、Webasmにコンパイルすると、そうすることによる重大な負荷と実行時のパフォーマンスのペナルティを回避できますか？ また、言語フルC VMをWebasmにコンパイルしてそのようにした場合、パフォーマンスの問題が発生しますか？

他の言語を使用すると、避けられないパフォーマンスの問題が発生したり、（パフォーマンス上の理由で）その言語の仕様に違反する場所がたくさんある場合は、JavaScriptの部分的な置き換えであり、一般的に、新しいコードよりもレガシーコードの移植に多く使用されています。 JavaScript」（JSにうまくコンパイルするように設計されたCoffeeScript、TypeScriptなどを除く）。

これらの問題は解決できますか？ たとえば、新しいRuby-> Webasmコンパイラを使用して、現在のブラウザJavaScriptと同等のパフォーマンスを実現しますか？

例としてJavaScriptとRuby（Opalを使用）を使用するには（私が試したものとして、基本的に以前に放棄したものとして）：

+演算子を使用するJavaScriptでは、数値を文字列に変換できます。

5 + " example" === "5 example"

Rubyはタイピングがはるかに強力であり、それは許可されていません。

5 + " example"
#TypeError: String can't be coerced into Integer

そのため、オパールは独自のプラスを作成する必要があり、多くのコアタイプに対してかなり複雑なメソッドを作成する必要があります

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

同様に、多くの基本的な操作について。

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

理論的には、JITはそれを完全に最適化できるかもしれませんが、それらが近いとは思いません（マイクロベンチマークはありませんでしたが、プロトタイプアプリ/ページ全体でRubyバージョンは大幅に遅くなりました）。オプティマイザーの生活はもっと大変ですか？

それでも、いくつかの問題が間違っているか、サポートされていません（ただし、Webasmにはネイティブの整数があるため、JSではなくWebasmにコンパイルする場合は開始できれば幸いです）。

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Javascriptコードを記述しなくても、C＃を使用して完全に機能するWebアプリを記述できます。

はい、それは非常にすばらしいことです（WebAssemblyにコンパイルする予定の言語に取り組んでいます）が、WebAssemblyがなくても、すでにそれを実行できるというのが私のポイントです。

wasmに直接コンパイルし、必要に応じてJavascriptでAPIマスクレイヤーまたはブリッジを作成できるため、開発者ベースはWebappでWebアプリケーションを開発するためにJavascriptを知る必要はありません。つまり、ASP.netではなく純粋なWebapp、JSPのようなフレームワークです。

確かに、そしてそれはもう何年もの間すでに可能でした。 WebAssemblyを待つ必要はありません。今すぐ始めることができます。asm.jsは数年前から存在しています。

@wnewbery

多くの言語はすでにJavaScriptにコンパイルできますが、Webasmにコンパイルすると、そうすることによる重大な負荷と実行時のパフォーマンスのペナルティを回避できますか？ また、言語フルC VMをWebasmにコンパイルしてそのようにした場合、パフォーマンスの問題が発生しますか？

解析時間には役立つかもしれませんが、実行時のパフォーマンスに役立つ可能性は低いです。

何かを明確にしましょう。asm.jsは数年前から存在しています。 これにより、プログラムをJavaScriptにコンパイルでき、そのプログラムはほぼネイティブの速度で実行されます。 つまり、デスクトップで実行するのと同じ速度でプログラムを実行できます。

そのため、言語を取得し、そのVM、ランタイム、およびガベージコレクターをasm.jsにコンパイルすることはすでに可能であり、その後、デスクトップとほぼ同じ速度で、ブラウザーで任意の言語を実行できます。 これはすでにかなり前から可能でした。

ただし、VM、ランタイム、およびガベージコレクターをコンパイルすると、ファイルサイズが非常に大きくなります（数メガバイト）。

また、JS API（DOMなど）との通信は困難です。

しかし、とにかくそれを行って、PyPyインタープリターをasm.jsにコンパイルするPyPy.jsのようなものを作成した人もいます。

CPythonよりもます（はい、本当に！ JavaScriptにコンパイルされ、ブラウザーで実行されているPyPyインタープリター実行されます！）

しかし、ファイルサイズはかなり悪いです（5メガバイトのgzip圧縮、15メガバイトのraw）。

asm.jsにRubyのVM +ガベージコレクタ+ランタイムをコンパイルすることができ、そしてそれは非常に高速になりますが、それはそれらの問題を持っているでしょう、あなたはそう。 したがって、代わりに人々はオパールのようなものを作成します。

WebAssemblyは、asm.jsの次の進化形です。 現時点では、WebAssemblyでできることは何でも、asm.jsでもできます。

そのため、言語+ VM +ランタイム+ガベージコレクターをWebAssemblyにコンパイルすることは可能であり、ほぼネイティブの速度で実行されます。

ただし、もちろん、asm.jsと同じ欠点があります。ファイルサイズが非常に大きく、JSAPIとの通信が困難です。

WebAssemblyとasm.jsには7つの違いがあります。

1. WebAssemblyは、一般的にasm.jsよりもわずかに（5％）高速です。

2. 64ビット整数を使用している場合、WebAssemblyはasm.jsよりも大幅に（〜400％）高速です。

3. WebAssemblyははるかに高速に解析できます。 これはプログラムの実行速度を改善しませんが、WebAssemblyを使用すると初期ロード時間が速くなることを意味します。

4. WebAssemblyのファイルサイズはasm.jsのファイルサイズよりも小さくなっています（約10〜20％小さい）。

5. WebAssemblyは将来、 asm.jsにはない素晴らしい機能（スレッド、同時実行性、ゼロコスト例外など）を取得する可能性

6. WebAssemblyは、将来、JavaScriptのガベージコレクターにアクセスできるようになる可能性

7. WebAssemblyは、将来、JS API（DOMなど）を簡単に使用できるようになります。

ただし、将来的にも、言語のVM +ランタイムをWebAssemblyにコンパイルする必要があるため、ファイルサイズは依然として問題になります。

言語のVM +ランタイム+ガベージコレクターをasm.jsにコンパイルすることが受け入れられない場合は、WebAssemblyを使用しても受け入れられない可能性があります。

また、言語のVM +ランタイム+ガベージコレクターのコンパイルが許容できる場合は、asm.jsを使用して今すぐコンパイルできます（後でWebAssemblyに簡単に移行できます）。

これらの問題は解決できますか？ たとえば、新しいRuby-> Webasmコンパイラを使用して、現在のブラウザJavaScriptと同等のパフォーマンスを実現しますか？

WebAssemblyの目的は、ネイティブ速度でプログラムを実行することです。 つまり、デスクトップで実行するのと同じ速度で実行します。

したがって、RubyをWebAssemblyにコンパイルすると、Rubyがデスクトップで実行されるのと同じ速度で実行されます。

Rubyはかなり遅い言語です。 遅い言語と遅いプログラムは、WebAssemblyでコンパイルした場合でも、依然として遅いです。

1 / 2 == 0.5 # Should be 0, Ruby has integer division

これはOpalのバグであり、 $rb_divide関数の定義を変更するだけで修正できます。

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

これは、Opalに文字列をJavaScript配列（変更可能）にコンパイルさせることで修正できます。

@Pauan

WebAssemblyは将来、asm.jsにはない素晴らしい機能（スレッド、同時実行性、ゼロコスト例外など）を取得する可能性があります。

スレッドは多くの言語、ライブラリ、フレームワークにとって非常に重要な機能です。スレッドがないと、マルチスレッドに依存するc ++、c＃、javaによって作成された多くのアプリは、奇妙な動作を引き起こす可能性があるため、webappに変換することはできません（SIMDのような別の良いことは言うまでもありません） _将来（？）_）をサポートします。 要するに、asm.jsはパフォーマンスも移植能力も十分ではないと思います。もしそれが良ければ、ずっと前にasm.jsに「移植」されたライブラリがもっとあるはずです。

javascriptは非常に人気があり、レガシーサポートのためになくなるだけではないと誰もが言っているように、ほとんどのブラウザは引き続きjavascriptのネイティブ実行をサポートしますが、将来的にはjavascriptを使用して新しいWebサイトを作成する人は、パフォーマンスを向上させるためにそれをwasmにコンパイルすると思います

@unmellow 、その神話を再び暴くために：JSをWasmにコンパイルしても、魔法のパフォーマンスが向上することはありません。まったく逆です。 JSエンジンが提供できるよりも優れたパフォーマンスが必要な場合は、より優れた言語を選択する必要があります。

ええごめんなさい私はそれがより速く解析することを意味したことを忘れました
編集：ブラウザがサポートするようにJavaScriptエンジンを更新していない場合でも発生する可能性があります
新しいバージョンのjavascriptセンスの人々は、パフォーマンスを損なうことなくwasmにコンパイルできました

私は1年前のチケットを蹴るのはあまり快適ではありませんが、議論のために、そしてほんの少しの怒りです。

多くの人がJavascriptをWASMに置き換えるという考えに懐疑的であることがわかりますが、1つは、WASMは実際にはパフォーマンスだけではないということです。 人々がほとんど忘れているのは、Javascriptが彼らが望む（または望んでいた）言語ではないということです。 つまり、少なくとも、ベアボーンJavascriptは人々が望んでいるものではありません。 基本的にサードパーティ言語のコンパイラであるトランスパイラーを使用する人がますます増えています。 これは単に、人々が標準への依存

しかし、変換は、その性質上、コンパイルよりもはるかに困難です。 ある言語を別の言語にマッピングする数学的問題は、必ずしもローカルスコープに限定されるわけではありません。 一部のコンテキスト情報は反対側に持ち越される必要があり、正しく行うことは難しい問題です。 そのため、Javascriptに似ていないトランスパイラーは広く採用されていません（または、それらに依存すべきではありません）。

また、重複した作業には問題があります。 トランスパイラーはコンパイラーであり、バンドラーはリンカーです。 私たちは皆、何年もの間それらのツールを持ってきました。 モジュール、ツリーシェイク、コード分割、動的/遅延読み込み、アセット管理など。真に新しいものはありませんが、Web専用のこれらの機能を備えた新しいツールが必要であり、Web以外のソリューションには適していません。

WASMが1日ですべてを変えるわけではありません。 Javascriptには現在、十分に構築されたエコシステムがありますが、他の言語にはありません。 Javascriptが実際にどこかに行くまでには時間がかかりますが、長期的には明らかに起こります。

Javascriptは、私が考えているように、ひどい方向に向かっているので、WASMの置き換えを歓迎します。 大幅な改善はあったものの、過去数年間で多くのコミュニティや方向性が誤解されてきたと思います。 適切な言語を歓迎します。必ずしもその代わりになる必要はありませんが、直接の競争相手になるため、この新しい不快なJSのフレーバーとその「フレームワーク」を書く必要はありませんでした。

@spencerudnick Cからは得られないパフォーマンス向上のためのアセンブリを作成したことはありませんか？