現代のフロントエンド開発ではReactが事実上の標準となり、多くの開発現場で採用されています。
しかしその一方で、Hooksの概念が複雑化し、「状態管理のためのコードがロジックの本質を覆い隠してしまう」という状況に直面する開発者も少なくありません。
いわゆるHooks地獄です。
特に中規模以上のアプリケーションになると、useStateやuseEffectの依存関係が増え、少しの変更が予期せぬ副作用を生むことがあります。
その結果、コードの可読性や保守性が徐々に低下し、「なぜこの処理がここにあるのか」を追跡するだけで時間を消費するケースが増えていきます。
こうした状況に対して、本記事ではあえてReactを前提としない選択肢、つまり素のJavaScriptに近い開発スタイルに立ち返ることのメリットを論理的に整理します。
これは単なる回帰ではなく、設計の自由度と透明性を取り戻すための合理的な判断でもあります。
例えば次のような観点から再評価する価値があります。
- フレームワークの抽象化による認知負荷の低減
- DOM操作や状態遷移の明示性の向上
- ビルドツール依存の最小化による環境の単純化
これらは一見すると「昔に戻る」ように見えますが、実際にはシステムの複雑性を制御するための戦略的な選択です。
特に長期運用を前提としたプロダクトでは、このシンプルさが大きな武器になります。
本記事では、Reactを否定するのではなく、あえて距離を取ることで見えてくる設計上の本質について掘り下げていきます。
Hooks地獄とは何か：React開発で起きる状態管理の複雑化
Reactは宣言的UIという思想のもとで設計されており、コンポーネント単位で状態と描画ロジックを整理できる点が大きな利点です。
しかし実務レベルでアプリケーションが成長すると、その抽象化が逆に複雑性を生み出す局面が出てきます。
その代表例がいわゆるHooks地獄です。
Hooksは関数コンポーネントに状態管理や副作用処理を導入する仕組みですが、設計を誤るとロジックが分散し、全体の制御フローが追いにくくなります。
特にuseStateとuseEffectの組み合わせが増えるほど、コンポーネントは「状態の集合体」と化し、本来のUIロジックとの境界が曖昧になります。
useEffect依存関係がもたらす予測不能な副作用
useEffectは外部副作用を扱うための重要な仕組みですが、依存配列の設計が不適切だと実行タイミングが直感とズレることがあります。
このズレはバグとして顕在化するまで気付きにくいという性質を持っています。
例えば以下のようなコードは一見単純ですが、依存関係の追加や削除によって挙動が変化しやすい構造です。
useEffect(() => {
fetchData(userId);
}, [userId]);
このように依存配列は「何に反応して再実行されるのか」を明示する一方で、依存の増加に伴い副作用の発火条件が複雑化します。
結果として、変更の影響範囲が予測しづらくなるという問題が発生します。
特に複数のuseEffectが同一の状態に依存している場合、実行順序や競合状態が問題になることもあります。
これは宣言的であるはずのReactにおいて、実質的に暗黙の制御フローが生まれている状態と言えます。
状態管理の増加がコードの可読性を下げる理由
アプリケーションが大規模化するにつれて、状態の数は必然的に増加します。
しかしその状態がすべてコンポーネント内部に閉じている場合、コードの認知負荷は急激に上昇します。
状態が増えること自体は問題ではありませんが、問題となるのは「状態同士の関係性がコード上で明示的に整理されないこと」です。
結果として、以下のような構造的問題が発生します。
状態の種類 | 影響範囲 | 可読性への影響。
—|—|—。
ローカル状態 | 単一コンポーネント | 比較的高い。
共有状態 | 複数コンポーネント | 低下しやすい。
副作用依存状態 | 非同期処理連動 | 低い。
このように状態が増えるほど、コードは「何をしているか」ではなく「どの状態がいつ更新されるか」に焦点が移ってしまいます。
その結果、ビジネスロジックよりも状態遷移の追跡に時間を取られる構造になります。
本質的には、ReactのHooksは柔軟性と引き換えに「状態の可視性」を部分的に犠牲にしています。
そのため設計次第では非常に強力である一方、ルールが曖昧なまま運用すると一気に複雑性が増幅するという特徴を持っています。
useStateとuseEffectが生む依存関係の罠と可読性の低下
ReactにおけるuseStateとuseEffectは、本来はシンプルな状態管理と副作用処理を提供するための仕組みです。
しかし実務で複数の状態と副作用が絡み合うようになると、それぞれのHooksが独立しているにもかかわらず、実質的には強い依存関係を形成するようになります。
この構造的な問題が、コードの可読性を徐々に低下させる主要因になります。
特に注意すべき点は、状態の更新と副作用の実行が異なるタイミングで発生することです。
これにより、開発者の頭の中で「状態の流れ」と「副作用の流れ」を同時に追跡する必要が生じ、認知負荷が増大します。
さらに、状態が増えるほどコンポーネント内部の責務は曖昧になります。
本来であれば単一の関心事に集中すべきコンポーネントが、複数の状態管理ロジックを抱えることで、結果的に「小さな状態管理システム」のような構造へと変質していきます。
Hooksの増加によるロジック分断の問題
Hooksが増えること自体は設計上の柔軟性を意味しますが、それがそのまま保守性の向上につながるわけではありません。
むしろ、ロジックが関数単位で分断されることで、処理の全体像が見えにくくなるという問題が発生します。
例えば以下のように、同一コンポーネント内で複数のHooksが並列的に存在する場合、それぞれの関係性はコード上では明示されません。
const [count, setCount] = useState(0);
useEffect(() => {
document.title = `Count: ${count}`;
}, [count]);
useEffect(() => {
fetchUserData();
}, []);
このような構造では、「countの更新」と「副作用としてのタイトル変更」が密接に関係しているにもかかわらず、その関係性はコードの物理的な位置関係からは読み取れません。
結果として、コードレビューやバグ修正時に、影響範囲の把握に余計な時間がかかることになります。
また、Hooksは関数呼び出しの順序に依存するため、条件分岐や早期returnと組み合わせた場合に制約が発生します。
この制約がさらにロジックの配置を歪め、自然な構造ではなく「Hooksルールに従うための構造」を強制する形になります。
このような状態が積み重なると、コンポーネントは単なるUI単位ではなく、複数の隠れた状態機械の集合体として振る舞うようになります。
その結果、変更の影響範囲が予測しづらくなり、軽微な修正でも意図しない副作用を引き起こすリスクが高まります。
本質的には、useStateとuseEffectの組み合わせは強力である一方で、「設計の明示性」を開発者側が意識的に補完しなければ、可読性と保守性が急速に劣化するという性質を持っています。
Reactアプリが複雑化する構造的な理由と設計負債
Reactはコンポーネントベースの設計によって再利用性と関心の分離を実現するフレームワークです。
しかし、アプリケーションが成長するにつれて、その構造的な特性が逆に複雑性を生み出すことがあります。
これは単なる実装ミスではなく、設計思想そのものが持つトレードオフによるものです。
特に問題となるのは、コンポーネントが増えることで全体構造の把握が困難になる点です。
小さな単位に分割されたロジックは一見整理されているように見えますが、それらがどのように連携しているのかはコード上から即座に読み取れません。
この「局所的な明瞭さ」と「全体的な不透明さ」のギャップが設計負債として蓄積していきます。
さらに、状態管理や副作用が各コンポーネントに分散することで、アプリケーション全体としての振る舞いを理解するために複数のファイルを横断的に追う必要が生じます。
この構造はスケーラビリティと引き換えに認知コストを増加させる典型的なパターンです。
コンポーネント分割が逆に複雑性を増すケース
コンポーネント分割は本来、コードの再利用性と可読性を高めるための手段です。
しかし分割粒度が細かくなりすぎると、逆に全体構造が断片化し、理解コストが増加します。
例えばUIの一部をButtonコンポーネントやInputコンポーネントとして切り出すこと自体は自然ですが、それらがさらに複数のHooksやロジックを内包し始めると、単一のUI要素を理解するために複数の抽象層を追跡する必要が出てきます。
このような状態では、開発者は「どこで何が行われているのか」を把握するために、ファイル間を行き来する時間が増加します。
その結果、変更の影響範囲を正確に予測することが難しくなり、修正作業が局所的であっても全体的な検証が必要になるという非効率が発生します。
状態の流れが見えなくなる設計上の問題
Reactアプリの複雑化において最も本質的な問題は、状態の流れがコード上で明示的に追いにくくなる点です。
特にuseStateやuseContext、さらには外部状態管理ライブラリが混在する場合、データフローは複数の経路を持つことになります。
この構造では、ある状態の変更がどのコンポーネントに影響を与えるのかを静的に把握することが困難になります。
結果として、開発者は実行時の挙動を頼りにデバッグを行う必要が増えます。
以下のような状態共有構造を考えると、その複雑性はより明確になります。
状態の種類 | 共有範囲 | 追跡容易性。
—|—|—。
ローカル状態 | 単一コンポーネント | 高い。
props経由 | 親子関係 | 中程度。
コンテキスト | アプリ全体 | 低い。
このように、状態の共有範囲が広がるほど追跡容易性は低下します。
特にコンテキストを多用した設計では、どのコンポーネントがどの状態に依存しているのかがコード上で直接的に表現されないため、依存関係の全体像を把握することが難しくなります。
この結果として、Reactアプリは機能的には正しく動作していても、構造的には理解しづらい「ブラックボックス化」へと進行していきます。
これは短期的な開発速度と引き換えに、長期的な保守性を損なう典型的な設計負債の形です。
素のJavaScriptで開発するメリット：シンプルなDOM操作と明示性
フロントエンド開発においてフレームワークは強力な抽象化レイヤーを提供しますが、その一方で内部で何が起きているのかを見えにくくする側面も持っています。
素のJavaScript、いわゆるVanilla JSでの開発は、その抽象化を一度取り払い、ブラウザAPIと直接向き合うアプローチです。
この方法は一見プリミティブに見えますが、システムの振る舞いを正確に理解するという意味で非常に本質的です。
特にDOM操作に関しては、フレームワークを介さないことで処理の流れが直線的になり、コードと実行結果の対応関係が明確になります。
これはデバッグ時の予測可能性を大きく向上させます。
また、抽象層が少ないため、パフォーマンスチューニングの際にもボトルネックの特定が容易になります。
さらに重要なのは、開発者が「隠されたルール」を覚える必要がないという点です。
Reactのようなフレームワークでは、ライフサイクルやHooksのルールを正しく理解していないと意図しない挙動を引き起こしますが、素のJavaScriptではそのような抽象的制約が少なく、コードそのものが仕様として機能します。
フレームワークなしでコードの意図が明確になる
Vanilla JSの最大の利点は、コードの意図がそのまま実行フローとして表れることです。
例えばDOMの更新処理を考えた場合、フレームワークを介さず直接操作することで、何がいつ変更されるのかが明確になります。
const button = document.querySelector("#btn");
const counter = document.querySelector("#count");
let count = 0;
button.addEventListener("click", () => {
count++;
counter.textContent = count;
});
このコードでは、状態更新とUI更新の関係が一対一で記述されており、抽象的な中間層が存在しません。
そのため、処理の流れを追う際に別のファイルやライブラリ内部の挙動を参照する必要がなくなります。
また、コード全体の意図が「イベントを受けて状態を更新し、その結果をDOMに反映する」という単純な構造に収束しているため、認知負荷が非常に低くなります。
これは小規模から中規模のアプリケーションにおいて特に有効であり、設計の透明性を重視する場合には大きなメリットとなります。
一方で、このアプローチはスケーラビリティの面では別の設計工夫が必要になりますが、それでもなお「何が起きているのかを完全に把握できる」という性質は、複雑化したフレームワーク環境に対する強い対比となります。
パフォーマンス最適化の視点から見るReact vs Vanilla JS
フロントエンドのパフォーマンスを議論する際、ReactとVanilla JavaScriptの比較は単純な優劣では語れません。
それぞれが異なる設計思想を持っており、最適化のアプローチも本質的に異なります。
Reactは仮想DOMを用いた差分更新によってUI更新を効率化しますが、その分抽象化コストが存在します。
一方でVanilla JSは直接DOMを操作するため、更新処理そのものは単純ですが、設計次第でパフォーマンス特性が大きく変化します。
重要なのは「どのような規模と頻度でUI更新が発生するか」という観点です。
小規模な更新ではVanilla JSの直接性が有利に働き、大規模で複雑な状態変化がある場合にはReactの差分アルゴリズムが有効になるケースがあります。
また、実行効率を考える際には単純な処理速度だけでなく、レンダリングの再計算回数やメモリ使用量も考慮する必要があります。
特にReactでは再レンダリングのトリガーが状態管理に依存するため、設計次第では不要な再描画が発生することもあります。
レンダリングコストの違いと実行効率
レンダリングコストという観点では、ReactとVanilla JSの違いは「間接性の有無」に集約されます。
Reactは仮想DOMを介して変更差分を計算し、最小限のDOM更新を行うため、一見すると効率的です。
しかしこのプロセス自体に計算コストが存在し、コンポーネント数が増えるほどその影響は無視できなくなります。
一方でVanilla JSは、必要な箇所だけを直接操作するため、理論上のオーバーヘッドは最小限です。
ただし、設計が不十分な場合にはDOM操作が散在し、結果として管理コストが増加するというトレードオフがあります。
比較を整理すると以下のようになります。
- Reactは差分計算による最適化を内部で自動化する
- Vanilla JSは開発者が最適化方針を直接制御する必要がある
- 小規模更新ではVanilla JSが低コストになりやすい
- 大規模UIではReactの一貫した更新モデルが有利になる場合がある
このように、レンダリングコストの本質は「何を自動化し、何を開発者が制御するか」という設計思想の違いにあります。
例えば、単純なカウンター更新のようなケースでは、Vanilla JSは余分な抽象化が存在しないため非常に高速に動作します。
しかし、複数のコンポーネントが連動するダッシュボードのようなケースでは、Reactの差分更新機構が全体最適化に寄与することがあります。
重要なのは、どちらが常に優れているかではなく、システムの複雑性と更新頻度に応じて適切に選択することです。
パフォーマンス最適化は単なる速度比較ではなく、設計判断そのものに深く依存しているという点を理解する必要があります。
状態管理を減らす設計思想とアーキテクチャの再考
フロントエンドアーキテクチャを長期的に安定させるうえで重要になるのが、「状態をどこまで持つか」という設計判断です。
Reactをはじめとするモダンフレームワークは状態管理の仕組みを豊富に提供していますが、それがそのまま最適解になるとは限りません。
むしろ状態が増えすぎることで、アプリケーション全体の振る舞いが不明瞭になり、変更の影響範囲が予測しにくくなるという問題が発生します。
この問題の本質は、状態そのものではなく「状態の共有範囲」にあります。
ローカルに閉じた状態であれば影響範囲は限定されますが、グローバルに近づくほど依存関係は指数的に増加し、システムの複雑性が増大します。
そのため、設計段階で状態をどのレイヤーに配置するかは、単なる実装上の選択ではなくアーキテクチャ上の意思決定になります。
グローバル状態に依存しない設計の利点
グローバル状態管理は一見すると便利ですが、依存関係を可視化しにくくするという副作用を持っています。
特にアプリケーション規模が大きくなると、どのコンポーネントがどの状態を参照しているのかを静的に追跡することが難しくなります。
その結果、変更時の影響範囲が広がり、軽微な修正でも予期しない副作用を引き起こすリスクが高まります。
これに対して、グローバル状態に依存しない設計は以下のような利点を持ちます。
- 状態の影響範囲が局所化されることでデバッグが容易になる
- コンポーネント単位でのテストが独立して実施しやすくなる
- 依存関係が明示的になり、コードレビュー時の理解コストが低下する
- 状態遷移のトレーサビリティが向上する
これらの利点は単なる可読性の改善にとどまらず、システム全体の健全性に直結します。
特に重要なのは、状態の変更が局所的であるほど「システム全体を再解釈する必要性」が減るという点です。
これは開発速度だけでなく、長期的な保守性にも大きく影響します。
例えば、コンポーネント内部で完結する状態設計では、そのコンポーネントの挙動はコードを読むだけでほぼ完全に把握できます。
一方でグローバル状態に依存した設計では、状態の定義箇所と使用箇所が分離されるため、実行時の文脈を補完しなければ理解できない構造になります。
この違いは小さなプロジェクトでは顕在化しにくいものの、コードベースが拡大するにつれて急激に影響を及ぼします。
そのため、設計段階で「状態を共有する必要性が本当にあるのか」を慎重に評価することが、アーキテクチャ品質を維持する上で極めて重要になります。
開発環境の選択：VSCodeやCursorで変わるフロントエンド体験
フロントエンド開発において、使用するフレームワークやライブラリと同じくらい重要なのが開発環境の選択です。
特に近年は、エディタの進化が開発体験そのものを大きく変えています。
従来は単なるコード編集ツールだったものが、今では補完、静的解析、リファクタリング支援まで統合された統合開発環境として機能しています。
この文脈で代表的なのがVisual Studio CodeやCursorのような軽量かつ拡張性の高いエディタです。
これらのツールはフレームワークに強く依存しない開発スタイルと相性が良く、特に素のJavaScriptでの開発においてその真価を発揮します。
重要なのは、フレームワークに依存しない構成では「開発者自身がシステム全体を把握する必要がある」という点です。
そのため、エディタ側の支援が直接的に生産性へ影響します。
重い抽象化レイヤーに頼らない分、環境そのものが思考速度に直結する構造になります。
軽量エディタが素のJavaScript開発を加速する
軽量エディタの最大の利点は、余計な抽象化を排除しつつも必要十分な支援機能を提供する点にあります。
特にVanilla JavaScriptのようにフレームワーク依存が少ない開発では、コードの構造がそのまま実行ロジックに直結するため、エディタの補助機能が理解速度に直結します。
例えば、以下のような単純なDOM操作を考えた場合でも、補完機能や定義ジャンプがあることでコードの追跡コストが大幅に削減されます。
const el = document.querySelector("#app");
el.addEventListener("click", () => {
el.textContent = "clicked";
});
このようなコードは本質的にシンプルですが、アプリケーションが拡大すると関連するイベントや状態が増加し、手動での追跡は困難になります。
その際にエディタが提供する静的解析や参照検索機能は、フレームワークの補助機構に近い役割を果たします。
また、軽量エディタは起動速度やレスポンスの軽快さにも優れているため、思考の中断を最小限に抑えることができます。
これは特にロジックを逐次的に組み立てる素のJavaScript開発において重要な要素です。
結果として、軽量エディタを用いることで「抽象化に頼らず、環境で補完する」という設計思想が成立します。
これはフレームワーク依存を減らしつつも、開発効率を維持するための現実的なアプローチと言えます。
Reactを捨てるのではなく距離を取るという実践的アプローチ
フロントエンド開発の現場において、Reactのようなフレームワークを「使うか捨てるか」という二択で捉える議論はしばしば極端になりがちです。
しかし実務的な観点から見ると、重要なのは採用の有無ではなく、どの程度の距離感で付き合うかという設計判断です。
フレームワークは強力な抽象化ツールである一方で、その抽象化が過剰になるとシステム全体の透明性を損なう可能性があります。
特にアプリケーションの規模やライフサイクルが多様化する現代では、すべての場面でReactを全面的に適用することが最適解とは限りません。
むしろ部分的に素のJavaScriptを併用することで、設計の自由度と可視性を両立できるケースも多く存在します。
このアプローチの本質は「フレームワークに設計を委ねる」のではなく、「フレームワークを設計の一部として制御する」という発想への転換です。
必要な場面だけフレームワークを使う判断基準
Reactを使うかどうかの判断は、技術的好みではなく構造的要件に基づいて行う必要があります。
特に重要なのは、状態の複雑性、UIの再利用性、そしてチーム規模という三つの軸です。
まず、状態が単純で局所的に完結する場合には、フレームワークの抽象化は必ずしも必要ではありません。
むしろVanilla JSのような直接的な実装の方が、理解コストと実装コストの両面で優位になることがあります。
一方で、複数のコンポーネント間で状態が共有され、かつ頻繁に更新されるようなシステムでは、Reactのような宣言的UIフレームワークの恩恵が明確に現れます。
この場合、差分更新やコンポーネント分割による管理性の向上が重要な価値になります。
判断の目安を整理すると以下のようになります。
- 状態が単一コンポーネント内で完結する場合はVanilla JSが有効
- UIの再利用性が高い場合はReactが有効
- チーム開発で責務分離が必要な場合はReactが有利
- 小規模ツールや内部スクリプトではフレームワーク不要な場合が多い
このように整理すると、Reactは万能な解決策ではなく「特定の複雑性を管理するためのツール」であることが明確になります。
また重要なのは、両者を排他的に扱う必要はないという点です。
実際のプロダクトでは、コア部分にReactを使用しつつ、軽量なUIやユーティリティ部分には素のJavaScriptを用いることで、全体の複雑性を抑えながら開発効率を維持することが可能です。
結果として、Reactとの距離を適切に保つという考え方は、単なる技術選択ではなく、アーキテクチャ設計そのものに対する成熟したアプローチと言えます。
Hooks地獄から抜け出すための現実的な結論
ReactにおけるHooksは、関数コンポーネントに状態管理と副作用処理を導入するための強力な仕組みです。
しかし実務レベルでアプリケーションが成長すると、その柔軟性がそのまま複雑性へと転化する局面が必ず発生します。
いわゆるHooks地獄とは、単なるコードの書き方の問題ではなく、設計思想とスケーリングの不一致から生じる構造的な問題です。
この問題を解決するために重要なのは、Hooksを減らすこと自体を目的化しないことです。
むしろ本質的な課題は「状態と副作用の配置をどのように制御するか」という設計レベルの判断にあります。
Hooksを適切に使うことは当然として、それ以上に「どの情報をReactの管理対象にするべきか」を見極める必要があります。
実務的な観点から見ると、すべてのロジックをReactの内部状態として扱う必要はありません。
むしろ、明示的な制御が必要な部分と、フレームワークに任せる部分を分離することで、コードの可読性と保守性は大きく改善されます。
このとき重要になるのが、状態の責務分離です。
例えばUIに直接関わる状態と、ビジネスロジックとして扱う状態を混在させると、useEffectやuseStateの依存関係が複雑化しやすくなります。
結果として、変更の影響範囲が予測しづらくなり、軽微な修正でも意図しない副作用が発生するリスクが高まります。
一方で、すべてを外部に逃がす設計も現実的ではありません。
重要なのはバランスであり、以下のような観点で整理することが有効です。
- 状態がUIの表示制御のみであればローカルに保持する
- 複数コンポーネントで共有される場合のみ外部化を検討する
- 非同期処理や副作用は可能な限り分離して管理する
- 再利用性が低いロジックは無理に抽象化しない
これらの原則を守ることで、Hooksの過剰な連鎖を抑制し、コードの構造を単純化できます。
また、設計上のもう一つの重要な視点は「状態の流れをどれだけ追跡可能にするか」です。
Reactの宣言的モデルは強力ですが、状態の遷移経路が複雑になると、実行時の挙動を頭の中で再構築する必要が生じます。
この負担が積み重なると、開発速度は徐々に低下します。
そのため、Hooks地獄から抜け出すという課題は、単にコードを減らすことではなく、システム全体の認知負荷を下げることに他なりません。
具体的には、状態の集中管理を避け、局所性を維持し、依存関係を明示的に保つことが重要になります。
最終的な結論として、Reactを完全に否定する必要はありません。
しかし、すべてをReactの抽象化に委ねるのではなく、必要に応じて素のJavaScriptやよりシンプルな構造を組み合わせることで、設計の透明性を維持することができます。
これは「フレームワークに従う開発」から「フレームワークを制御する開発」への移行であり、長期的な保守性を考えた場合に非常に重要な視点となります。
コメント