なぜjQuery UIは巨大になったのか技術的背景 - Web開発における知見共有系ページ

jQuery UIは重い、巨大、読み込むとページが遅くなる――この印象は間違いではありません。
しかし理由を「コンポーネントが多いから」と考えると、本質を見誤ります。

実際には、jQuery UIはUIライブラリではなく「ブラウザ互換性の塊」だったため巨大になりました。

当時のWeb開発では、「ボタンを押したらモーダルが出る」だけでも一大事件でした。
現在のブラウザでは当たり前に動くドラッグ＆ドロップやアニメーション、フォーカス制御が、ブラウザごとに全く違う挙動をしていたからです。

つまり、jQuery UIが提供していたのは見た目ではなく、「どのブラウザでも壊れない挙動」でした。

2008年前後のフロントエンド開発では、次の問題が同時に存在していました。

例えば「モーダルダイアログ」を考えます。
現在ならposition: fixedとz-indexで終わります。しかし当時のIE6ではfixedが使えません。スクロールするとダイアログが一緒に動いてしまいます。

これを解決するには、

といった処理を全部書く必要がありました。
jQuery UIのコード量は、見た目のためではなく、この対策のために増えていきました。

代表的なコンポーネントを見てみます。

これらはUI部品に見えますが、実際には「イベント制御エンジン」です。
特にDraggableは象徴的です。

ドラッグ操作は単純に見えますが、実際には

をすべて処理します。
しかもブラウザごとにイベント名や発火タイミングが違いました。

つまりjQuery UIは、UIを提供しているのではなく、「正しくマウスを扱う仕組み」そのものを提供していたのです。

jQuery UIが巨大化したもう1つの理由が「Widget Factory」です。
これはコンポーネント作成のための基盤でした。

$.widget("ui.sample", {
  _create: function(){
    this.element.addClass("active");
  }
});

この書き方で、状態を持つUIコンポーネントが作れます。

なぜ必要だったのでしょうか。
通常のjQueryプラグインは「1回処理して終わり」です。しかしUI部品は違います。

といった「継続的な状態管理」が必要になります。
そのため、jQuery UIは単なるプラグインではなく、小さなフレームワークを内部に持つようになりました。結果としてファイルサイズが急増します。

さらに重要なのがCSSです。
現在のCSSはflexboxやtransformがありますが、当時は使えませんでした。

例えば中央配置だけでも、

をJavaScriptで実装していました。

つまりjQuery UIはJavaScriptライブラリでありながら、CSSレイアウトエンジンの代替も担っていたのです。これが「重さ」の正体でした。

当時の企業システムでは、次のような状況が珍しくありませんでした。

このとき、jQuery UIを入れると一気に解決します。
自作すると数週間かかる機能が数分で動きました。多少重くても採用された理由はここにあります。

ただし副作用もありました。
1つのダイアログのために全体を読み込むケースが多く、パフォーマンス問題の原因にもなりました。jQuery UIが「とりあえず入れておくライブラリ」になると、ページが極端に遅くなることもありました。

現在のブラウザは次の機能を標準で持ちます。

つまり、jQuery UIが解決していた問題の大半が消えました。
役割がなくなれば、巨大なライブラリは不要になります。

jQuery UIが巨大だったのは設計の失敗ではありません。
当時のブラウザ環境があまりにもバラバラだったため、その差異を吸収した結果です。

現在の軽量なフロントエンドは、ブラウザが進化した恩恵の上に成り立っています。
jQuery UIは重かったのではなく、ブラウザの未完成さを肩代わりしていたライブラリだったと言えるでしょう。