1. Ionicとは「UIコンポーネント層」に過ぎない

Ionicとは、モバイル向けUIをWeb技術で表現するためのコンポーネント群です。

• Ionic Components = Web Components
• 描画処理はWebViewのDOM/CSSエンジン
• Ionic自身は状態もロジックも持たない

つまり、IonicはUIの形だけを定義する層であり、アプリの振る舞いを決定する力は一切ありません。

この「空白」をどう埋めるかが、Angular / React / Vue の役割になります。

2. Ionicアプリの実行単位をレイヤーで分解する

Ionicアプリの内部は、次のレイヤーで動いています。

重要なのは、Ionicはロジック層に一切介入しないという点です。

3. 画面ライフサイクルと状態寿命のズレ

Ionicには独自の画面ライフサイクルがあります。

• 画面はキャッシュされる
• 非表示でもDOMが破棄されない場合がある
• 戻る操作で状態が復元される

一方で、Angular / React / Vue にはそれぞれ別のライフサイクルがあります。

ここで次の問題が生まれます。

• 画面は存在するが、状態は破棄されている
• 状態は残っているが、画面は再生成される

このズレをどこで吸収するかが、フレームワークごとに固定されます。

4. Ionic + Angular：状態がServiceに固定される理由

Angularでは、状態はServiceに集約されるのが一般的です。

• Serviceはアプリ全体で共有
• Componentは表示責務
• DIにより参照関係が固定

Ionic上では、これが次の構造を生みます。

• 画面が破棄されてもServiceは生き続ける
• 状態の初期化タイミングが不明確になる
• 非同期処理が画面外で継続する

結果として、「画面に紐づかない状態」が増殖します。
これはAngularの設計思想がIonicの画面管理と噛み合わないために起きる必然です。

5. Ionic + React：再レンダリング境界が設計になる瞬間

Reactでは、状態変更＝再レンダリングです。

Ionic ComponentsはDOM構造が深く、Reactの差分計算は以下の影響を受けます。

• 状態をどこに置くか
• どのコンポーネントでuseState/useContextを使うか
• 再レンダリング範囲をどこで切るか

結果として、

• パフォーマンス対策のために状態を分割
• UI構造が状態境界に引きずられる
• Hooksの構成が設計そのものになる

Ionic + Reactでは、再レンダリング境界＝アプリ設計になります。

6. Ionic + Vue：リアクティブ依存が構造を曖昧にする

Vueはリアクティブシステムが非常に強力です。

• 状態変更が即DOMに反映
• テンプレートと状態の距離が近い

Ionicと組み合わせると、

• Ionic Component内で直接状態操作
• computed / watchが増える
• 状態の所有者が不明確になる

結果として、UIが状態を内包する構造ができあがります。

後から状態管理を分離しようとしても、影響範囲が広すぎて切り出せません。

7. 同一UIでも内部構造が分岐する具体例

同じ「一覧 → 詳細」画面でも、

• Angular：Serviceが一覧・詳細の状態を保持
• React：画面コンポーネントが状態を分割管理
• Vue：テンプレートと状態が密結合

UIは同じでも、状態の流れは完全に別物になります。

8. 技術者が本当に見るべき選択軸

選択基準は人気や学習コストではありません。

この問いに答えた時点で、選択肢はほぼ一つに絞られます。

Ionicとは、UIを提供するだけで、実行モデルを一切決めないフレームワークです。その空白をAngular・React・Vueがそれぞれ異なる方法で埋めることで、状態寿命、再描画境界、非同期処理の構造が固定されます。どれを選ぶかは好みではなく、どの設計制約を受け入れるかという判断です。Ionicを使う以上、フレームワーク選択はアーキテクチャ選択そのものになります。