jQueryは消えていない。むしろ「消せない」
jQueryはもう使われていない、という話をよく聞きます。
しかし実際の現場では、今でも非常に多くのシステムで動き続けています。
これは単なる「古いから残っている」のではありません。
結論から言うと、jQueryは現代のフロントエンドの代替ではなく、別の領域を担当しているためです。
ReactやVueが解決する問題と、jQueryが解決する問題は重なっていません。
Webアプリと業務画面は別物
現在のフロントエンドの議論は、SPAを前提に語られることが多いです。
しかし現場のシステムの多くはSPAではありません。
例えば次のような画面です。
- 管理画面
- 社内申請システム
- CMSの編集画面
- ECサイトの管理ページ
これらは「ページ遷移」が存在します。
つまり画面はHTMLとしてサーバから生成されます。
このタイプの画面では、必要なのはUIフレームワークではなく「少しの動き」です。
- 入力チェック
- モーダル表示
- 並び替え
- Ajax送信
まさにjQueryが得意としていた領域です。
導入コストの差
SPAフレームワークを導入するには、次の準備が必要になります。
- ビルド環境
- Node.js
- 依存パッケージ管理
- コンポーネント設計
- 状態管理
小さな管理画面にとっては過剰です。
一方jQueryなら、scriptタグ1つです。
<script src="/js/jquery.js"></script> <script> $("#save").on("click", function(){ alert("保存しました"); }); </script>
これで動きます。
つまり、ページ単位の開発ではjQueryの方が合理的です。
サーバサイドとの相性
多くの業務システムはサーバサイドレンダリングです。
- PHP
- Java（Spring）
- Ruby on Rails
- ASP.NET
これらはHTMLを出力する仕組みが強力です。
jQueryはこのモデルと非常に相性が良いです。
なぜなら、HTMLが存在している前提で動くからです。
SPAは逆に、サーバの役割をAPIに限定します。この変更はアーキテクチャ全体に影響します。
つまりjQueryは、サーバ中心設計のフロントエンドとして今も成立しています。
既存システムという現実
もう1つ重要な理由があります。既存資産です。
企業システムは10年以上動き続けます。
数十万行のJavaScriptをReactに書き直すことは、技術的には可能でも現実的ではありません。
- 仕様が固定されていない
- 担当者が変わっている
- テストが不足している
この状態で全面刷新は大きなリスクになります。
そのため、多くの現場では「動いているjQueryを維持する」という判断になります。
小さな機能追加に強い
実務では「少しだけ直したい」が頻繁に発生します。
- ボタンを1つ追加
- 確認ダイアログを出す
- Ajaxで1項目更新
このとき、コンポーネント設計から始めるのは非効率です。
jQueryはピンポイントの変更に非常に強いです。
$("#delete").on("click", function(){ if(confirm("削除しますか？")){ $.post("/delete", { id: 10 }); } });
短いコードで完結します。
注意点
ただし、新規の大規模フロントエンドをjQueryで構築するのは適していません。
画面数が増えると、イベント管理が散在し、保守が難しくなります。
特に、
- 画面遷移がないアプリ
- 複雑な状態管理
- リアルタイム更新
ではSPAフレームワークの方が明らかに有利です。
つまり、jQueryは万能ではありません。
向いている問題領域がはっきりしているライブラリです。
最後に
jQueryは流行から外れましたが、用途から外れたわけではありません。
ドキュメント型のWeb、サーバ中心の画面、管理系UIでは今も合理的な選択肢です。
技術は「新しいか古いか」で選ばれるわけではありません。
解決したい問題に対して適しているかどうかです。
jQueryが現場に残っているのは、過去の名残ではなく、現在でも解決している問題が存在するからです。
