何故 jQuery ではなく React/Vue/Svelte が流行するのか？

こんにちは。 jQuery から商業プログラミングに入門したやまゆです。

なぜ jQuery だと古い、ダメだと言われるのでしょうか？いいじゃん。 $.ajax で簡単にデータ引っ張ってこれるし、 $("#btn").click(function () { alert("押した！"); }); は誰が見ても何が起こるか一瞬で分かる Simple さがあるじゃん。なんでわざわざ React/Vue/Svelte その他 jQuery ではないライブラリを使わなければならないんでしょうか？ 100 億回言われてきたことだと思いますが、私なりに振り返ってみます。

手続き型 UI と宣言型 UI

$("#btn").click(function () {
    alert("押した！");
});

は、手続き型です。 btn という ID の DOM 要素を取得して、それらの(一応複数になる可能性があります)要素に対して click イベントハンドラを登録します。

この処理が実行される前と後では、 既に存在している DOM 要素の状態が変わっていますね。これが手続き型です。上から順番に変化させていくスタイルです。削除するには、同様に手続き型で削除しなければなりません。つまり、全ての関連コードを見ても 「今 DOM 要素はどういう状態？」 というのが非常に分かりづらいという欠点があります。

function Button() {
  function onClick() {
    alert("押した！");
  }
  return <button type="button" onClick={onClick}>押す</button>;
}

対して React の例ですが、これは宣言型です。つまり、「この DOM 要素はこうあるべき」という理想形を定義しています。ここに定義された <button> 要素以外の状態には一切影響がありませんし、 <button> 要素を操作することはこの Button 関数以外は出来ません(基本的には)。そのため、 Button 関数さえ見れば、その DOM 要素の状態が完全に理解できます。他のコードを参照する必要はありません。

この違いが現代のフロントエンドパラダイムでは非常に重要になってきます。

以前の GUI

React などが生まれるよりもずっと前から UI を作成するフレームワークはたくさんありました。代表例としては Visutal C++ を使って Win32API を駆使する手法や Macintosh の QuickDraw など、 90 年代からあります。 Win32API に関しては、物によっては現在も使われている可能性もありますね。互換性の高さがうかがえます。

これらの GUI は、 GUI を使って視覚的に構築することが多かったです。つまり、「フォーム」のウィンドウに「ボタン」をドラッグ＆ドロップして配置し、そのクリックイベントにクリックした時の動作コードを割り当てる、といった形です。

もちろん GUI を使わず全て C++ コードだけで GUI を記述することも可能でしたが、作業効率的に GUI で作った方がとっつきやすいしいいですよね。

これも、ドラッグ＆ドロップしたボタンの状態は GUI で確認できるので、いつの間にか移動していたり消えていたりすることは少ないです（例外はあり）。

つまり、過去の GUI 作成も 「宣言型」 に近い作り方をしていたのです。 jQuery 側が新しいやり方 だったのです。

jQuery は新しいやり方

これは、ブラウザの役割の変化によるものが大きいです。

当初ブラウザは HTML 文書で組み立てられた静的な（動いたり要素が消えたり増えたりしない）文字列を閲覧するためのものでした。

しかし、 JavaScript による動的な操作が可能になったり、 Ajax と呼ばれる非同期の HTTP リクエストを送信できるようになったりした結果、ブラウザは動的な（動いたり要素が消えたり増えたり する )要素を描画するものに変化します。

この 静から動 を支えたのが jQuery と呼ばれるライブラリです。

ECMAScript 5 と呼ばれる仕様が JavaScript の仕様として長らく使われていたのですが、これは API が結構操作しづらいものでした。その API をラップし、 $("#btn") これだけの記述で DOM 要素を取得したり、簡単に ajax リクエストを送れるような超便利な世界にしたのが jQuery です。

jQuery の登場により、ブラウザは革命的に変化を迎えます。元々「文書」だったものが、よりインタラクティブに動くものに変わっていったのです。まさに Win32API のようなインタラクティブ性 を得ました。

さて、ここで問題が生まれます。自由にいじれるようになった結果、最初に述べた 「今の DOM 要素の状態がどこでどうなっているのかわからない」 ようになってしまいました。 20 行目の jQuery コードが 1,800 行目の DOM 要素に影響したりします。人間の手には負えなくなってしまいました。

それを解決するために、いくつかのプロジェクトが動き出しました。それが、今の React/Vue/Svelte などです（ほかにもたくさんあります）。

jQuery の問題は「どの DOM 要素をどこからでもいじれることが出来る」という、自由度が高すぎることです。

そこで、各プロジェクトは、 「あえて自由度を下げ制約を設ける」 ようにしました。具体的には、 Win32API を Visual C++ の GUI でいじれるかのように、要素ごとに分離したのです。

これは要するに、各要素を 「手続き型から宣言型に変更した」 と言うことも出来ると思います。

宣言型の利点

手続き型も宣言型もやることは一緒です。最初に提示したコードはほぼ同じ挙動を示します。違いはなんでしょうか？

それは、 「べきとう性」 が大きいです。べきとう性とは、「何度実行しても同じ結果が得られること」です。 jQuery にはべきとう性がない操作（破壊的な操作と言います）が大半です。

Button 関数でラップされた「状態と振る舞い（あれ？これはクラスでは？）」は、どこで使っても同じ結果を得ることが出来ます。

※ここで一つ注釈が必要になってきました。何も言わず React のサンプルコードは JavaScript に HTML DOM 要素を記述しています。この書き方は jsx と呼ばれ、 React による JavaScript の拡張記法です。現在は React 以外でもこの書き方が出来るものが増えてきました(mdx とかもあります)。

結論

jQuery が何故良くなくて、これらのライブラリの方が良いよ、と呼ばれる理由がなんとなくわかりましたでしょうか？

ソースコードは何事も 「わかりやすい」 方が良いです。 React は JavaScript の中に HTML を埋め込めるようにしてわかりやすくしました。 Vue は 1 ファイルに HTML/CSS/JS を書けるようにしてわかりやすくしました。このように 「よりわかりやすい」 方を使った方が、後からコードを読んで理解出来る人間が増えるという極上のメリットが得られます。

もちろん、 React を使って「わかりづらい」コードを書くこともできます(TypeScript も型注釈も使わない、 props を多用するなど、バッドプラクティスと呼ばれるもの)。しかし、 React 等それぞれのライブラリは「こう書くと良いよ」というベストプラクティスを提供しているものが多いです。それに従って書けば、わかりやすいコードを書けるようになります。ベストプラクティス最高。

未来

最近は急速に 「生成 AI による GUI の自動生成」 が流行しています。これは必然とも言えます。何故なら、筆者としてはその視覚効果を表現する CSS が難しすぎると思うからです。もっと簡単に GUI は作れるようにするべきで、そこに生成 AI が入るでしょう。是非みなさんも一回使ってみると良いと思います。

しかし、生成 AI が提供する GUI は、見た目こそ良いものの、後から保守しようとなった時に裏で生成されている大量の CSS を見てげんなりするのではないでしょうか。多分。私使ったことないのでわかりませんが。なので、自分で CSS を頑張って勉強する必要も引き続きあると思います。自戒も込めて。