1. Ionicを「フレームワーク」と呼ぶ理由

Ionicは、ランタイムや独自エンジンを持つ実行基盤ではありません。

それでもフレームワークと呼ばれる理由は、アプリ構築に必要な前提条件を一式として定義している点にあります。

具体的には以下です。

• Web Componentsとして実装されたUIコンポーネント群
• モバイルUIを前提に設計されたDOM構造とCSS設計
• WebView上で動作することを前提とした制約条件
• JavaScriptフレームワークと組み合わせる前提の責務分離

つまりIonicは、「どう書けばWebアプリをモバイルアプリとして成立させられるか」を構造レベルで規定するフレームワークと言えます。

2. Ionicアプリの実行単位は何か

Ionicアプリを実行単位で分解すると、以下のようになります。

• 実行コード：HTML / CSS / JavaScript
• 実行環境：OS標準のWebView
• 起動形態：ネイティブアプリからWebViewを起動

ここで重要なのは、IonicアプリはOSから見ると「WebViewを内包したネイティブアプリ」であり、WebViewから見ると「通常のWebアプリ」である、という二重構造です。

Ionicはこの両者の間に位置し、実行制御自体は行いません。

3. HTMLはどこで解釈されているのか

Ionicで記述されたHTMLは、すべてWebView内のブラウザエンジンで解釈されます。

• ion-headerやion-content は独自タグに見える
• 実体は Web Components（Custom Elements）

アプリ起動時、JavaScriptの初期化処理により、これらのカスタム要素が定義され、

DOMツリーは通常のHTMLと同様に構築されます。

IonicがHTMLを特別に解釈したり、独自DOMを生成することはありません。

4. CSSはどこまでがIonicの責務か

CSSにおけるIonicの責務は、主に「定義」と「切り替え」です。

• コンポーネント単位のスタイル定義
• CSS変数によるテーマ制御
• iOS / Android向けのスタイル分岐

一方で、

• CSSOMの生成
• レイアウト計算
• ペイント処理

はすべてWebViewのCSSエンジンが担当します。

そのため、Ionicを使っても、複雑なレイアウトや大量DOMによるコストはWebアプリと同様に発生します。

5. JavaScriptの実行環境と制約

JavaScriptは、WebViewに内蔵されたJavaScriptエンジン上で実行されます。

• iOS： JavaScriptCore
• Android：V8（System WebView）

実行モデルはブラウザと同じであり、

• メインスレッド中心の実行
• UIスレッドとの競合
• ガベージコレクションの影響

といった制約を受けます。

Ionic自体はJavaScriptの実行方式やパフォーマンスに介入しません。

6. WebView層の実態

WebViewは、Ionicが提供するものではなく、OSが提供する標準コンポーネントです。

• iOS： WKWebView
• Android： System WebView

Ionicは、これらのWebViewを「使わせてもらっている」立場にあります。

そのため、

• 描画性能
• CSS対応状況
• JavaScript実行特性

は、WebViewのバージョンや実装差に強く依存します。

7. レイヤー構造を図で整理する

この図から分かる通り、IonicはDOMより上、JavaScriptフレームワークとWebViewの間に位置しています。

Ionicは、HTML・CSS・JavaScriptをネイティブ化する魔法の仕組みではありません。
すべての処理はWebView上で行われ、Ionicはその上にモバイル向けUI構造と設計ルールを提供しているだけです。この境界を理解していないと、パフォーマンス問題や挙動差の原因を誤認します。Ionicを技術的に正しく使うためには、Webレンダリングそのものを理解することが前提となります。