jQuery と React / Vue の考え方の違いを１枚の画像で図示して説明してみる

# はじめに

なぜ jQuery でなく React / Vue を使いたいか、あるいは、どのような時に使うべきか、という話について、自分でかみ砕いたこれらの内容を１枚の図にまとめ、その説明を文章としてまとめた。

:::note warn
あくまで、考え方の違いだけを示しているので、正確ではない情報を含みます。 これらを比較・検討する考えの取っ掛かりとして利用することを想定しています。
また、あくまで個人的な見解をまとめたものです。 もし、あまりにも的外れな点があればご指摘下さい。
:::


# 図示と説明

![jQueryとReact/Vueの考え方の違い](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/502582/8b196495-6fa1-c911-5985-9fc01adcf709.png)


## jQuery や Vanilla JS を使う場合の考え方

最初にページが生成された後、イベント[^1]を起点にして **DOMの操作を行い自分自身を書き換えていく。** そしてこれを繰り返していき、ページ上に表現したいことを表現する。

[^1]: ユーザーからの操作など。 具体例としては `click` や `change` 。 


## React や Vue を使う場合の考え方

jQuery と異なり、変数として「状態」を持つ[^2]。状態の変更は、jQuery の場合と同様イベントによって行われる。 jQuery との大きな違いは、**イベントによる変更は、状態管理に注力しており具体的な DOM の操作を行わないこと。**  状態が変更されると、ページ [^3] 側も状態に応じて自動的に表示を変化させる。 具体的にどう実現するかは、各ライブラリが担保している。

別の観点として、図の中に Excel の表があるがイメージとしてはこれが身近で分かりやすい。 Excel ではセルの値が変化すると、その値を使った式を用いている別のセルの値が自動的に変化するのと同じように、「状態」が変化すると「ページ」の表示も自動的に変化する。 React や Vue を用いることで、この Excel と同じような仕組みを実現できる。

[^2]: jQuery などの場合はDOMで構成されたウェブページそのものが状態である、と捉えてもよいかもしれない。 それとは別に、明確な変数としてレンダリングに利用するための状態を持っている。
[^3]: なお、現実的には、ページではなくコンポーネントというページ内の部分要素が単位として使われると思うが、ここでは jQuery のケースと合わせるために、ページという単語をあえて用いている。

## どのような時に jQuery ではなく React / Vue を使いたいのか

**A. １つのページで多くのイベントが発生する、それらのイベントに強い関連性がある場合。 言い換えると、ページ上でのDOM操作の個数が多い・複雑な場合。**

先にも書いた通り、jQuery ではイベントが発生する時、ページにどんな変化を起こすかのDOM操作を合わせて記述することである時点のページを生成する。 具体的には、`hide` で表示を消したり、`addClass` や `css` でスタイルを変化させたりなどである。 あるいは、`append` などで新しく生成した DOM を加える場合などもこれにあたる。

これらが問題になるのは、操作順によって結果が異なるため、制御が複雑になることが１つ挙げられる。 例えば、`<ul>` の中の要素全てに `addClass` をする場合、以下の２つの操作があることになる。

- 操作1: `<ul>` に新しい要素を生成して追加する
- 操作2: `<ul>` 内の全ての要素の class を書きかえる

この２つの操作だけを見るとシンプルだが、適用する順番によって異なる結果が得られる。

- 操作1 -> 操作2: 追加された全ての要素の class が書き換えられる
- 操作2 -> 操作1: 追加前に存在していた全ての要素の class は書き換えられるが、その後に追加された要素の class は書き換えられない

そのため、どの順でこの操作が行われても開発者が意図した動きをさせたいと考えた場合、例えば、「操作2が行われた場合は flag を立てておいて、操作1が行われる時に flag を見て必要ならば追加時に初期で class を設定する」という風に考えてしまうだろう。 結果として、jQuery では操作1と操作2の間に関係ができ、これらの操作が強く結合してしまう。

今回は単純な例を挙げたが、実際のページ上ではこのような操作が数多く存在する。 そのためイベントに強い関連性が発生してしまい、管理が難しくなっていくのである。 さらに、これらがどのように関連しているかは jQuery のコード上でも DOM を経由してやり取りしているため、イベント同士に関連があるか否かを見分けるのも難しくなっており、これがコードの保守を難しくするという欠点がある。

一方、React / Vue の考え方である場合、要素を追加する場合は **ページの状態に要素の元となるデータを新しく追加することしかしない** し、class を書きかえる場合も、書き換え先の class 情報の名前を **ページの状態に設定するだけしかしない** 。 しかし、これらの状態の変更によって、その状態に依存したページ要素の再生成が行われる。 
**結果として、開発者はページの状態を書きかえることに注力するだけで現在必要なページ状態を表示するという目的を達成できるようになる。** 副次的な効果として、複数の操作の密結合の多くを解消したり、ページ内要素の関連性が分かりやすく整理されて保守しやすい状況が生まれる。

以上の点から、１つのページ上で多くのイベントや操作を扱う、つまり、インタラクティブ性の高いウェブページを作りたいと考える場合、開発容易性、保守性など [^4] の理由から React や Vue などのライブラリを使いたいというモチベーションが高くなるのである。

[^4]: その他にも仮想DOMを用いることによる描画の最適化などのパフォーマンス的な側面もある。


## jQuery を使っていいのはどんな時か？

**A. 十分に小さいページを対象とした開発の場合**

個人の所感だが、別段 jQuery というライブラリが悪いとは全く思っていない。 しかし同時に、React / Vue などを利用したリッチに動くウェブページが多くなってきている中で、同じことを jQuery で実施するのは（上述の理由から）辛そうで、実施したくないと強く思う。

そのため、ランディングページなどの専用作り切り、というページだったり、デザインがシンプルな昔ながらの form と画面が対応するような機能（いわゆる管理者向け機能）を開発している場合であったり、操作の制御の多くが疎結合で、それほど大きな機能を持つページでもないような場合は jQuery を使うことをそこまで毛嫌いしなくても良いとは思う。

ただし、最初は規模が小さいが、それが予想外に大きくなってしまっても jQuery での開発を続けると地獄を見るため、将来対象がどれだけ大きくなるかという点も併せて見定める必要があるだろう。 そういった意味では「具体的にどういった場合に何を使うべきか」には明確な解はないだろう。