概要

宣言的UI（Declarative UI） は、「状態（state）」をもとにUIを再構築する設計思想であり、
命令的UI（Imperative UI） は、ユーザー操作に応じてDOMを直接操作する設計思想です。
Reactなどのモダンフレームワークは、この宣言的UIを体系化したアーキテクチャを採用しています。
（参考：React – Thinking in React）

つまり、

宣言的UI：状態を唯一の真実のソース（Single Source of Truth）とし、UIを「状態の関数」として再描画する。
命令的UI：DOMを状態として扱い、イベント発生時に逐次的に変更命令を出す。
両者の違いは、UIを「何から導くか」（state か DOM か）にある。

本記事では、Vanilla JSを用いてこの２つの構造を比較し、
それぞれの基本構造テンプレートと設計思想上の違いを整理します。

目次

宣言的UIの基本構造
命令的UIの基本構造（インクリメンタル型）
宣言的UIと命令的UIを分ける構造的ポイント
宣言的と命令的を分ける本質
まとめ
参考リンク

宣言的UIの基本構造

宣言的UIとは、
「状態（state）を中心とし、UIをその写像として再描画する設計」です。
ReactやVueが採用する考え方を、Vanilla JSでも再現できます。

1. import / 初期設定セクション
2. DOM参照キャッシュ / 定数セクション

3. 関数定義セクション
│
├─ 3.1 データアクセス関数セクション（Storage I/O）
│     ├─ getState() / saveState()
│     └─ localStorageやAPI通信など
│
├─ 3.2 データ操作（ビジネスロジック）関数セクション（Model更新系）
│     ├─ addItem(), deleteItem(), updateItem()
│     └─ 状態を変更し、UI再描画関数を呼ぶ
│
├─ 3.3 イベントハンドラー関数セクション（Controller）
│     ├─ フォーム入力・ボタン押下などユーザー操作を処理
│     └─ データ操作関数を呼び出し、UI更新をトリガー
│
└─ 3.4 UI更新関数セクション（副作用を内包）
      ├─ 3.4.1 要素生成・属性設定
      ├─ 3.4.2 イベント付与
      ├─ 3.4.3 構造組み立て
      └─ 3.4.4 DOM挿入（状態の反映）

4. 初期化 / イベントハンドラー登録セクション

特徴

状態(state)を単一の真実源（Single Source of Truth）として管理
displayBooks() などのUI更新関数が 「状態→UI再描画」 のみを担当
イベントハンドラーは状態を更新するだけで、UIの再構築は別関数に任せる
DOM操作は明示的命令ではなく「状態の結果」として再生成される

処理フロー（概念図）

命令的UIの基本構造（インクリメンタル型）

命令的UIとは、
「DOM自体をアプリの状態とみなし、ユーザー操作ごとに直接命令で変更する設計」です。
jQueryや古いVanilla JSコードはこの形に該当します。

1. import / 初期設定セクション
2. DOM参照キャッシュ / 定数セクション

3. 関数定義セクション
│
├─ 3.1 イベントハンドラー関数セクション（直接DOM操作）
│     ├─ onClickAdd(), onClickDelete()
│     └─ 各関数がユーザー操作に応じてUI更新関数を呼び出す
│
├─ 3.2 UI更新関数セクション（副作用を内包）
│     ├─ 3.2.1 要素生成・属性設定（createElement, setAttribute）
│     ├─ 3.2.2 イベント付与（addEventListener）
│     ├─ 3.2.3 構造組み立て（appendChildでネスト構築）
│     └─ 3.2.4 DOM挿入／削除（画面への反映・除去）
│
└─ 3.3 ユーティリティ関数セクション（任意）
      ├─ バリデーション、ID発行、フォーマットなどの補助処理

4. 初期化 / イベントハンドラー登録セクション
│     ├─ アプリ初期化処理（init()など）
│     └─ イベントハンドラーをDOMにバインド

特徴

状態（state）を別変数で保持せず、DOMがそのままアプリ状態を表す
イベントハンドラーが appendChild() や removeChild() を直接実行
UI更新は逐次的（incremental）であり、状態とUIが一体化している
表面上は効率的だが、状態の整合性が崩れやすく、再現性が低い

処理フロー（概念図）

宣言的UIと命令的UIを分ける構造的ポイント

観点	宣言的UI	命令的UI
状態の所在	state / localStorage / API	DOM自身が状態を保持
UI更新のトリガー	状態変更（Model → View）	ユーザー操作（直接View更新）
UI更新関数の性質	状態をもとに再構築（全体再描画）	一部のノードを逐次操作
Controllerの責務	Model更新のみ担当	DOM操作を直接実行
一貫性・再現性	高い（stateからUIを再生成可能）	低い（DOM依存で再現困難）
代表的な例	React, Vue, Svelte, Vanilla再描画型	jQuery, Vanilla命令型

宣言的と命令的を分ける本質

両者の違いは、「UIを何から導くか」にあります。

概念	宣言的UI	命令的UI
UIの生成原理	UI = f(state)	UIを直接構築
アプリの真実のソース	state（モデル層）	DOM
再現可能性	状態があれば再構築できる	DOM操作履歴がなければ復元できない

つまり、宣言的UIの本質は「状態とUIの分離」にあります。
この構造を採用すると、アプリの再現性・テスト容易性・保守性が飛躍的に向上します。

6. まとめ

Vanilla JSでも、「状態を中心に再描画する構造」 を採用すれば宣言的UIを実現できる
命令的UIは、「UI＝状態」になっているため構造がシンプルだが拡張に弱い
両者の違いを決めるのは 「Model層（3.1〜3.2）」の有無
宣言的UIの採用により、状態管理とUIロジックが明確に分離され、
React的なアーキテクチャをVanillaでも構築できる

参考リンク