🧰

WASMの将来性について語る - JavaScriptもDockerも不要になる未来

に公開
WebAssembly
WebAssembly
frontend
idea

WebAssembly（通称WASM）と聞いて、皆さんはどんなイメージを持っていますか？

「RustやC++で書いたコードをブラウザで動かせる技術でしょ？」

確かにその通りです。しかし、WASMの可能性はそれだけに留まりません。

実は、WASMは今後のソフトウェア開発の常識を大きく変える可能性を秘めています。具体的には以下の2つです。

  • Web開発でJavaScriptが不要になる
  • Dockerに取って代わる可能性がある

「そんなまさか！」と思われるかもしれません。しかし、これは決して夢物語ではなく、今後1〜2年で現実になりつつある話なのです。

この記事では、WASMの基本から、なぜこのような未来が実現するのかを詳しく解説していきます。

WASMとは何か？

WASMの基本

WebAssembly（WASM）とは、様々なプログラミング言語をコンパイルして作られるバイナリコード形式、およびその仕様のことです。

現在、以下のような言語がWASMへのコンパイルに対応しています。

  • Rust
  • C/C++
  • Go
  • Python
  • Javascript/Typescript
  • その他多数

これらの言語で書かれたコードをWASM形式にコンパイルすることで、実行ファイルやライブラリなど、あらゆる処理を組み込むことが可能になります。

WASMランタイムの役割

WASMを実行するには「WASMランタイム」が必要です。これは、WASMバイナリを解釈して実行するための環境です。

ブラウザでの実行
現在、主要なブラウザ（Chrome、Firefox、Safari、Edgeなど）には既にWASMランタイムが組み込まれています。そのため、追加のインストールなしにブラウザ上でWASMを実行できます。

OS上での実行
サーバーサイドやローカル環境で実行する場合は、以下のようなWASMランタイムをインストールします。

WASMの革新性

ここで重要なのは、元々どの言語で書かれたコードでも、WASMにコンパイルすれば、ブラウザでもOS上でも同じように動作するという点です。

従来であれば：

  • ブラウザで動かすにはJavaScriptに書き直す必要があった
  • 異なるOS間で動かすには、それぞれの環境向けにビルドが必要だった

WASMを使えば：

  • 一度WASMにコンパイルすれば、どこでも動く
  • 実行する側はWASMランタイムさえあればOK
  • プログラムの配布が非常に容易

この時点で、言語やプラットフォームの垣根が大きく下がっていることがお分かりいただけるでしょう。

Web開発でJavaScriptが不要になる日

Component Modelという革命

WASMの仕様は現在も進化を続けています。その中でも特に注目すべきが「Component Model」という仕様です。

この仕様が完成し、ブラウザが対応を完了した時、Web開発に革命が起きます。

現在のWeb開発の制約

現状、Web開発には大きな制約があります。

WebAPI（DOM操作、fetch、イベント処理など）はJavaScriptでしか扱えない

そのため、どんなにRustやTypeScriptが好きでも、最終的にはJavaScriptにトランスパイルするか、JavaScriptを経由する必要がありました。

つまり、Web開発においてJavaScriptは「必須」だったのです。

Component Modelがもたらす変化

Component Modelが実現すると、ブラウザのWebAPIが直接WASMから呼び出せるようになります。

これが意味するのは：

  • RustでDOM操作ができる
  • Goでfetchリクエストを送れる
  • C#でイベントハンドリングができる

つまり、開発者は好きな言語でWeb開発ができるようになるのです。

いつ実現するのか？

この未来は遠い話ではありません。今後1〜2年の間に実現すると考えられています。

W3Cを中心に仕様策定が進められており、主要ブラウザベンダーも積極的に対応を進めています。

JavaScriptの未来

もちろん、JavaScriptがすぐに消えるわけではありません。

  • Web開発のエコシステムとして最も成熟している
  • 膨大な既存コードベースがある
  • 学習リソースが豊富

これらの理由から、しばらくはJavaScriptが主流であり続けるでしょう。
しかし、選択肢が増えることは間違いなく開発者にとってプラスです。

かくいう私も今まで大変お世話になったJavascriptですが、この未来が実現したらすぐに手放す予定。

WASMがDockerに取って代わる可能性

サーバーサイドでのWASM

WASMというと「ブラウザで動く技術」というイメージが強いですが、実はサーバーサイドでも大きな可能性を秘めています。

WASMランタイムをサーバーにインストールすることで、OS上でWASMを実行できます。では、これをどう活用できるのでしょうか？

Dockerとの共通点

現在、コンテナ技術の代表格であるDockerは、以下の理由で広く使われています。

  • 環境の一貫性：開発環境と本番環境を同じにできる
  • ポータビリティ：どこでも同じように動く
  • 依存関係の管理：必要なものを全てパッケージ化できる

実は、WASMもこれらの特性を持っています。

WASMの特性：

  • WASMランタイムさえあれば、どこでも同じように動く
  • 環境の違いを吸収できる
  • 依存関係をバイナリに含められる

WASMの優位性

さらに、WASMはDockerに比べて以下の点で優れています。

1. 圧倒的な軽量性

  • Dockerイメージ：数百MB〜数GB
  • WASMバイナリ：数KB〜数MB

2. 高速な起動

  • Dockerコンテナ：数秒
  • WASM：ミリ秒単位

3. セキュリティ

  • サンドボックス環境で実行される
  • デフォルトで最小限の権限しか持たない

現実的な展望

ただしWASMがDockerを完全に置き換えることは、現時点では考えにくいです。あくまで似たような機能を持っているものの、同じ目的のために設計されたものではないからです。

しかし、コンテナでタスクを実行したいなどといった、特定のユースケースでは確実にWASMが選ばれるようになるでしょう。実際、一部のCDNプロバイダーは、既にWASMを採用し始めているそうです。

今、多くの開発者が「Dockerは便利！もう手放せない！」と感じています。

しかし、数年後には「Dockerは便利だったけど大変だったよね。WASMの方が圧倒的に楽」と言われている未来が私には見えています。

まとめ

WebAssembly（WASM）は、単なる「ブラウザで他の言語を動かす技術」ではありません。

Web開発の未来

  • Component Modelにより、JavaScriptなしでWeb開発が可能に
  • 開発者は好きな言語を選べるようになる
  • 1〜2年以内に実現する可能性が高い

サーバーサイドの未来

  • Dockerよりも軽量で高速な実行環境
  • 部分的にDockerを置き換えていく

WASMは、フロントエンドとバックエンドの両方で、開発の常識を変える可能性を秘めています。

この技術の進化から、目が離せません。今のうちにWASMに触れておくことで、来たる変化に備えることができるでしょう。

Discussion