51
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

WebAssemblyのことを何となく分かったとなる

Last updated at Posted at 2020-06-18

WebAssemblyのことを何となく分かったとなる

WebAssemblyとは

モダンなブラウザで実行できる新しいタイプのコードです。
低レベルのバイナリで容量も小さく、ロードから実行までが高速です。
普段利用している言語はプロセッサ上で動くように機械コードへと翻訳され、プロセッサの種類によって機械コード・対応するアセンブリが必要になります。
WebAssemblyは特定の機械に対してではなく、ブラウザに対応しています。
WebAssemblyのコードをブラウザがインストールしたらどのマシンのアセンブリにも変換されます。

まとめ

・WebAssemblyはロードから実行までが早い
・プロセッサではなく、ブラウザに対応している
・WebAssemblyは低レベルなバイナリ

WebAssemblyの必要性

ブラウザ上ってJavaScriptいるやん・・・って思いますよねー。
JavaScriptいるのになんでWebAssemblyいるのって僕は思いました。調べました

JavaScriptさん「もう辛いっすよ!」

JavaScriptは技術の発展とAPIの整備の結果webGLや画像認識などを実装されるようになりました。
技術が発展し求めるものは「高速実行」です。
そもそもJavaScriptは動的型付け言語であって簡単に記述ができ、高速で実行するように考えられたものではないです。
JavaScript的には話が違うじゃないっすかーって感じでしょう。(仕事でもたまにあるやつ)
JavaScriptは型の情報が不足しているので、型が決まってないからチェックを1つ1つ行ってその結果によって命令を決めるようにするしかありません。
そのため高速実行は難しい。

JITコンパイルの登場

JavaScriptは型が決まってない!と言いましたがこの状況をどうにかするぞと考えJIT(Just In Time)コンパイルという技術が利用されます。
僕も詳しく説明ができないので要点をまとめますと
・すぐにネイティブコードにせずインタプリンタなどで動作させる
・変数に代入する値を観測してその統計して推定できるようになったらネイティブコードに変換する

JITコンパイルのおかげで高速動作させることができるようになりました。
しかし、まだ問題は存在しています。
・よく使うコードしかネイティブコードにならない
・高速動作させるためには時間が必要
・型の推定に失敗することがある

これらの問題を解決するためにasm.jsが導入されました。

asm.js登場

JITは高速に動作させることができましたが、時間がかかったりやり直しが必要になったり先ほどの問題があります。
これを解決するために実行する前にネイティブコードにコンパイルさせたい・・・けどJavaScriptはネイティブコードに出力するのは難しい。
そこでasm.jsが登場するわけです。
asm.jsにも詳しくないので何となく分かったとなるように要点だけまとめます。
・asm.jsの単位はモジュールでありファイル単位ではない
・JavaScriptの中でasm.jsのモジュールを定義する
・型の情報を明示する

asm.jsによってプログラムの中に型の情報を明示することによって事前コンパイルが可能になりました。
JITのように処理が重くなくなり高速に実行できますし、コンパイルされた結果はキャッシュされ次回からは高速に起動します。
しかし詳しくはソースコードを見てもらいたいんですが、書くのがめっちゃ大変です。
そのためにEmscriptenというツールが用意されていますが、Emscriptenで作られたコードはサイズが大きくダウンロードに時間がかかり起動までが長くなる。

この問題を解決するためにWebAssemblyが必要とされています。

WebAssembly登場

webAssemblyは冒頭で説明した通りで今までの課題を網羅しているでしょう。
WebAssemblyはファイルフォーマットの一種で拡張子に.wasmを利用します。
webで扱うのは大半がテキスト形式ですが、wasmはバイナリ形式でプログラムを表します。この違いがサイズが小さくなる理由です。

JavaScriptの場合、JavaScriptエンジンは実行時にパースしてコンパイル・コードの最適化を行わなければなりません。
パースでは抽象構文木というデータ構造に変換してバイナリ形式に変換させ、コンパイル時にはどの型が使われているかチェックする必要があります。
一方WebAssemblyは抽象構文木がバイナリ形式のおかげでデコードし静的であるためコンパイル時にチェックする必要もない。
そのため実行が早いという感じでしょうか。

個人的にもう1つの特徴としては、移植性だと思っています。
冒頭でも話したように、普段利用している言語はプロセッサなどに適合するようにソースコードをコンパイルさせなければなりません。
WebAssemblyはコンパイル手順を踏むだけで全てのモダンブラウザで実行ができます。
フロントでは踏み入れず諦めていたものもWebAssemblyを通せば解決するのではないでしょうか。

まとめ

・WebAssemblyはバイナリ形式
・JavaScriptよりも工程が少なくコンパイル時にチェックする必要もない
・実行がはえー
・移植性がある

JavaScriptはいるのか

ここまで学んできて思ったことはじゃあJavaScript必要ないんじゃないか?ってことです。
ここで僕が確かにと思った記事を引用させていただきます。

まずWebアプリの大半はasm.js/WebAssemblyで提供される計算性能を必要としていません。必要したとしても、大半のコードの価値はスピードよりもUXによって提供されるでしょう。JavaScriptの大きな特徴は、その生産性の高さです。高速に動作することよりも、高速に開発のイテレーションをまわ回して行く方が重要とされる局面は多くあるでしょう。そんな時にJavaScriptの生産性の高さが生きるでしょう。

https://html5experts.jp/chikoski/22523/

WebAssemblyが必要とされるのは、アプリの全てではなく複雑な処理を行う場面だと思っています。
僕の働く環境ではそこまで必要になることはないだろうし、開発を高速に回すことの方が重要な局面のが多いです。
このためJavaScriptとWebAssemblyは共存し合い、選択肢の1つに加わり、Webを豊かにしていくのが正しい道なのではないかと思っています。

51
35
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
51
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?