Garden

最近の記事

WEBフロントエンドは三銃士以外にある？ - wasmの可能性

16 min read

Prompt

WEBのフロントエンドは、本当にHtmlCssJavascriptだけなのか？

おお、Webのフロントエンドは本当にHTML、CSS、JavaScriptだけで成り立っているのか、という疑問だね！🚀

結論から言うと、Webブラウザが「直接」解釈できるのは HTML、CSS、JavaScriptの3つの言語だけ です。

しかし、現代のフロントエンド開発においては、これらの言語を直接手書きすることは稀で、**「この3つに変換される言語や技術」**を使って開発するのが一般的だよ。

🔑 ブラウザの制限と開発の現実

1. ブラウザが理解できる言語は3つだけ

Webブラウザ（Chrome、Firefox、Edgeなど）のレンダリングエンジン（V8、Geckoなど）が持つ**唯一のインタープリタ（解釈機能）**は、以下の3つに限定されています。

  • HTML: コンテンツの構造を定義する言語。

  • CSS: コンテンツの**見た目（スタイル）**を定義する言語。

  • JavaScript (JS): コンテンツの**振る舞い（ロジック）**を定義する言語。

君がReactやVueでどんなに複雑なコードを書いても、最終的にブラウザに届き、実行されるのは、ビルドツールによって生成されたこの3つの言語のファイルだけなんだ。

🛠️ 2. 開発で使われる「代替言語」の例

現代のフロントエンド開発者が使う言語や技術は、この3つの言語をより効率的に書くための**「上位概念」または「拡張機能」**だと考えられるよ。

A. JavaScriptの代替・拡張言語

これは、JavaScriptの欠点（特に型システム）を補うために、コンパイル時にJSに変換される言語だよ。

  • TypeScript (TS): 君も知見があるTypeScriptは、型安全性をJavaScriptに持ち込み、大規模開発を容易にする。最終的にはトランスパイラによってJavaScriptに変換される。

  • Dart/PureScript/ReasonML: JSとは異なる言語体系を持つが、Webブラウザで動かすためにJavaScriptへコンパイルされる。

B. CSSの代替・拡張言語

より柔軟なスタイル記述を可能にするために、CSSに**変数や関数、入れ子（ネスト）**といったプログラミング機能を追加した言語。

  • Sass/Less/Stylus: 独自の記法で記述され、プリプロセッサ（Preprocessor）によって標準のCSSファイルに変換されてブラウザに提供される。

C. HTMLの代替・拡張

  • JSX/TSX (React/Next.js): JavaScript（またはTypeScript）内でHTMLのような構文を記述できるようにする拡張機能。これはReactのcreateElement()関数呼び出しにトランスパイルされ、最終的に実行時にHTML要素を生成する。

🌐 結論：すべてはブラウザの「制約」

Webのフロントエンドは、この3言語の表現力の限界と開発の煩雑さを乗り越えるために、様々な代替技術を生み出してきたけど、それら全てが、ブラウザに届く前にHTML、CSS、JavaScriptへと変換される、というブラウザの制約に支配されているんだ。

だから、「フロントエンドは本当にこの3つだけなのか？」という質問に対する答えは、技術的にはイエス、開発プロセス的にはノー、ということになるね！😊

他に、これらの変換プロセスについて気になることはあるかい？

Prompt

つまりは、その三銃士の完全な代替となり得るポテンシャルをもつ技術は存在しないのか？

その通り、今のところHTML、CSS、JavaScriptの「三銃士」を完全に代替し、ブラウザ上でネイティブに動作するポテンシャルを持つ技術は存在しません。🚨

しかし、その支配を揺るがし、JavaScriptの役割を肩代わりしようと猛烈に挑戦している技術が存在します。それは、Webの世界で最も革命的な技術の一つであるWebAssembly (Wasm) です。

💻 1. WebAssembly (Wasm) の挑戦

WebAssemblyは、JavaScriptの最も重要な代替技術であり、**「JavaScriptに依存しないWebの実行環境」**を実現するポテンシャルを持っています。

Wasmが代替できるもの（JavaScriptの代替）

  • 目的: JavaScriptが苦手とする高性能な計算処理や、C++、Rust、C#などのネイティブコードのパフォーマンスをWebブラウザ上で実現すること。

  • 仕組み: Wasmは、ブラウザが理解できる低水準のバイナリ形式で、JavaScriptと並列して実行されます。これにより、ゲームエンジン、画像処理、複雑な物理シミュレーションといった、CPU負荷の高いアプリケーションをWebブラウザ上で高速に動かすことが可能になります。

  • ポテンシャル: Wasmは、将来的にはJavaScriptのロジックの大部分を置き換える可能性を秘めていますが、現在のところ、**DOM操作（UIの変更）**はWasmから直接行うことができず、JavaScriptを介する必要があります。

Wasmが代替できないもの（HTML/CSS）

  • HTML/CSS: Wasmはロジック層の技術であり、**Webページの構造（HTML）やスタイル（CSS）**を直接置き換えることはできません。Webサイトの見た目とレイアウトは、今後もHTMLとCSSが担い続けるでしょう。

🌐 2. 完全な代替技術が存在しない理由

WebAssemblyの登場をもってしても、この「三銃士」が支配的であり続ける理由は、ブラウザのアーキテクチャと歴史的経緯にあります。

  • ブラウザの共通規格: Webブラウザは、HTML/CSS/JSを解釈するためのレンダリングエンジンとJSエンジンを搭載することを、W3C（World Wide Web Consortium）などの標準化団体が定める唯一の共通規格としています。

  • 「Web」の定義: 「HTMLという構造と、ハイパーリンクによる文書の連携」こそがWebの定義そのものであり、これらを完全に捨てる技術は、もはや「Web」ではない別のプラットフォーム（例：モバイルアプリ）になってしまいます。

したがって、WasmがJavaScriptを高性能化する未来は現実的ですが、HTML/CSSというWebの骨格と皮膚を担う技術の地位は、今後も揺るがないと考えられます。😊

Prompt

なるほど、難しい質問だけど、WasmがDOMに対応するのはいつ？

おっ、WebAssembly (Wasm) が直接DOM操作に対応するのか、そしてそれがいつ実現するのか、という非常に未来志向で難しい質問だね！🚀

結論から言うと、WasmがDOMを直接操作する機能（いわゆるWasm-DOM）は、現在も開発・議論が続いていますが、すぐに実現する見込みは薄い、というのが現状だ。**「2025年時点では、まだ実験段階」**と考えておくのが正しいよ。

🚧 WasmがDOMに直接対応できない理由

Wasmは高性能な計算処理のために設計されており、そのセキュリティモデルと設計思想が、DOMへの直接アクセスを困難にしているんだ。

1. セキュリティモデルの壁 (Isolation)

Wasmは、ブラウザの他の部分から隔離されたメモリサンドボックス内で実行されるよね。

  • 安全性の担保: Wasmを設計した最大の目的の一つは、ネイティブコード（C++やRustなど）をWeb上で安全に実行すること。直接DOMにアクセスできるようになると、Wasmモジュールがブラウザ全体を混乱させたり、セキュリティ上の脆弱性を悪用したりするリスクが高まる。

  • DOM APIの複雑性: DOM APIは非常に大きく、複雑で、副作用が多い。Wasmがこれらを直接安全に操作できるように設計するのは、Wasmのシンプルなセキュリティモデルを崩壊させる可能性があるんだ。

2. JavaScriptとの協調（Wasm-JS Bridge）が必須

現在、WasmがDOMを操作する際は、必ずJavaScriptを橋渡し役として利用しているんだ。

  1. WasmモジュールがDOM操作の指示を出す。

  2. その指示がJavaScript側の**接着コード（Glue Code）**に送られる。

  3. JavaScriptがブラウザのネイティブDOM APIを呼び出して、実際の操作を行う。

この「ブリッジ」がオーバーヘッドとなるんだけど、Wasmの安全性を保つためには現時点では必須なんだ。

💡 将来的なアプローチ：インターフェース型の標準化

Wasmコミュニティは、DOMへの直接アクセスを目指すのではなく、より安全で抽象化された方法でDOMを扱うための規格化を進めているよ。

  • Interface Types (インターフェース型): これは、Wasmとホスト環境（ブラウザ、OSなど）の間で、より効率的に、かつ型安全にデータをやり取りするための標準規格。

  • Web IDLとの統合: この規格を使って、DOM APIの複雑さをWasm側で安全に抽象化し、JSを介さずに呼び出せるようにする方向で議論が進んでいる。

結論として、WasmがDOMに直接対応するのは、これらのインターフェース型の標準化と、ブラウザベンダー間の合意ができてからになる。これは数年単位の時間がかかる大規模な作業であり、2020年代後半に実用的なものが登場するかどうか、という状況だよ。

現時点では、**「WasmはJavaScriptを介してDOMを操作する」**と覚えておくのが正しいね！😊

Prompt

では、Glue Codeであっても仕方なく、その操作を抽象化し扱いやすくするものは存在する？(たとえばRustで)

もちろん、存在するよ！まさにその通り、**Glue Code（接着コード）**のオーバーヘッドは避けられないとしても、その操作を抽象化し、Rustなどの言語から安全かつ扱いやすくするためのライブラリやツールは、積極的に開発されているんだ！🚀

これは、**「WasmがJavaScriptの支配に挑む」**上で、Glue Codeをいかに効率的に書くかが非常に重要になるからだね。

🛠️ Glue Codeを抽象化する主要な技術

この分野で最も影響力があり、Rustコミュニティで広く使われているのは、wasm-bindgen というツールだね。

1. wasm-bindgen (ワズム・バインデン)

これは、RustのWasmモジュールとJavaScriptの間で、複雑なデータの受け渡しをスムーズに行うためのRust公式のツールだよ。

  • 目的: JavaScriptとRustの間の**呼び出し規約（ABI）**を自動で処理し、手書きするGlue Codeの量を大幅に削減する。

  • 抽象化の仕組み:

    • 型変換の自動化: Rustの複雑な型（String、Vec、カスタム構造体）と、JavaScriptの型（string、Array、Object）の間で、データのシリアライズ（直列化）とデシリアライズを自動で安全に行う。

    • JS/DOM APIの利用: Rustコード内で、まるでRustの関数であるかのように、JavaScriptの**alert()やDOM API**を呼び出せるように抽象化する。

    • 属性（Attributes）: Rustの関数や構造体に、#[wasm_bindgen] のような属性を付与するだけで、ツールが必要なGlue Codeを自動生成してくれるんだ。

2. web-sys と js-sys

wasm-bindgenの裏側では、これらのライブラリがGlue Codeの具体的な実装を提供しているよ。

  • web-sys: Web API（DOM、Console、Windowなど）全体をRustの型システムに持ち込むための、自動生成された低レベルのRustバインディング。これにより、JavaScriptを経由してWeb APIを呼び出すことができる。

  • js-sys: プリミティブ型（Date、Promise、Objectなど）やJavaScriptのグローバル関数を扱うためのバインディング。

💡 Rustでの開発体験

これらのツールのおかげで、Rust開発者はGlue Codeをほとんど意識することなく、以下のようなコードを書くだけでDOMを安全に操作できるんだ。

Rust

// #[wasm_bindgen]がGlue Codeを生成してくれる
#[wasm_bindgen]
pub fn greet(name: &str) {
    // web_sys を介して、JavaScriptの alert() を呼び出す
    web_sys::window().unwrap().alert_with_message(&format!("Hello, {}!", name));
}

このアプローチにより、Wasmの性能とRustのメモリ安全性というメリットを享受しながらも、JavaScriptの機能を簡単に利用できるようになっているんだね！Glue Codeは避けられないけど、それを**「人間が触らない安全な生成物」**にすることで、開発効率を維持しているというわけだ！😊

グラフビュー

最近の記事

グラフビュー