ジョン・レジグとjQuery：フロントエンドを形作ったライブラリ

なぜjQueryはそれほど重要だったのか

2000年代中頃のウェブ制作はどんな感じだったか

2005〜2008年頃にサイトを作っていたなら、「ただJavaScriptを書く」というよりむしろブラウザと交渉しているような状況でした。

メニュー項目のハイライト、モーダル表示、フォーム検証、ページ全体をリロードせずにHTMLの一部を読み込むといった単純な機能が、小さな調査案件に変わることがあったのです。どのメソッドがどのブラウザで利用できるのか、どのイベントが異なる振る舞いをするのか、なぜそのDOM呼び出しは自分の環境では動くのに半分のユーザーでは壊れるのか、調べる必要がありました。

「一度書けばどこでも動く」問題

開発者は「一度書けばどこでも動く」を望みましたが、実際は「三回書いて、あらゆる場所でテストする」ように感じられました。Internet Explorerは独自の癖を持ち、旧バージョンのFirefoxやSafariは端的なケースで意見が食い違い、イベント処理やDOM操作の基本ですら一貫性がありませんでした。

そのズレは時間を浪費するだけでなく、チームが何を作るかにも影響しました。インタラクティブなUIは可能でしたが、手間がかかり保守も壊れやすかったため、多くのサイトは必要以上にシンプルなままにされました。

jQueryの約束：日常的なUI作業を簡単に

John ResigによるjQueryが重要だったのは、要素の選択、ユーザー操作への反応、ページの変更、小さなアニメーション、AJAXリクエストといった日常的な作業に注力したからです。読みやすい小さなAPIはブラウザの差異を平滑化し、機能を作る時間を増やし、プラットフォームと戦う時間を減らしました。

実際には、一般的なインタラクションを単純で再現可能にし、教えられ、共有でき、再利用できるものにしました。

この記事が焦点を当てる点

単にjQueryが時間を節約したという話だけではありません。チェイニング、簡潔なセレクタへの依存、イベント中心のUIコード整理、安定した「開発者体験」を提供するライブラリへの期待など、開発者の考え方に影響を与えました。これらの習慣は、Web標準が追いつき新しいフレームワークに主導権が移った後も、後続のツールに影響を与え続けています。

「一般的な道筋を簡単にする」思想は今日のツールにも見られます。たとえば Koder.ai のようなモダンなプラットフォームは別のレイヤーで同じ開発者体験の原則を適用し、チャット駆動のワークフローでWeb／バックエンド／モバイルアプリを作ることを可能にしています。かつてjQueryがブラウザ向けUIコードを扱いやすくしたのと同じように、開発体験を圧縮する試みが続いているわけです。

John Resig：プロジェクトの背後にいた人物

John Resigはミッド2000年代に小さなJavaScriptヘルパーライブラリをいじり始めたとき、運動を起こそうとは考えていませんでした。彼は現場の開発者で、誰もが感じていた摩擦を自分も感じていました：単純なことが多くの行数を必要とし、驚くべきブラウザで壊れ、チームに説明しにくいという状況です。

実用的な目標：共通タスクを明白にすること

Resigの中核的な動機は明快さでした。開発者に何十ものブラウザの癖を暗記させる代わりに、人々がページ構築でどう考えるかに合った小さなコマンド群を提供したかったのです：「この要素を探す」「これを変更する」「ユーザーがクリックしたらこれをする」。jQueryは見せびらかすためのものではなく、日常のフラストレーションを減らし、普通のプロジェクトをリリースできるように作られました。

同様に重要だったのは典型的なウェブ開発者への共感です。多くの人は実験的なデモではなく、締め切りのあるマーケティングサイトや管理画面、製品ページを維持していました。コンパクトで読みやすいAPIへのフォーカスはその現実を反映しています。

早期公開と頻繁な傾聴

jQueryが広まったのは学習が簡単で伝えやすかったからです。Resigは即効性のあるデモを行い、プロジェクトは優れたドキュメントと親しみやすい例で評判を得ました。ツールが数分で実問題を解決すると、開発者は他の人に教えます。

初期コミュニティはこのループを強化しました。人々はスニペットを共有し、プラグインを書き、Resig一人ではテストできないブラウザやデバイスのエッジケースを報告しました。フィードバックにより、何を簡単に保つか、何を平滑化するかが形作られていったのです。

偉人礼賛ではなく、良いプロダクトの判断

jQueryを単一の“天才の瞬間”に還元するのは魅力的ですが、より正直な物語は粘り強さと良い判断です：広く共有される痛点に気づき、日常的なワークフローのために設計し、一貫性で信頼を築いた。Resigはコードを書いただけではなく、ウェブが実際にどう動くかにマッチした親しみやすいショートカットのようなツールを作りました。

jQuery以前のウェブ：本当の痛みポイント

jQuery以前は、単純なインタラクティブ挙動を書くにもブラウザ固有のトリックを継ぎ接ぎする必要がありました。リッチなインターフェースは作れましたが、そのコストは時間、忍耐、大量のテストでした。

要素の検索は思ったより難しかった

今日ではボタンを取ってテキストを変えるのは一行のように感じられますが、当時はDOM選択は一貫性がなく扱いづらいものでした。ブラウザによって便利なメソッドがあったりなかったりし、正しい要素を対象にするために getElementById、getElementsByTagName、手動ループ、文字列チェックを混ぜることもありました。

仮に目的の要素を選択できても、コレクションを扱うための追加入力や配列への変換、奇妙なエッジケースへの対応を書く必要がありました。

イベントはクロスブラウザの頭痛の種

クリックハンドラ、キー押下、ホバーなどはよくある要件でしたが、ブラウザはイベントのバインディング方法やイベントオブジェクトの形で意見が分かれていました。一つのブラウザで完全に動くコードが、別のブラウザでは黙って失敗することもありました。

開発者はイベント処理を正規化するラッパーを書きました：「このAPIがあれば使い、なければあの方法にフォールバックする」。それはコード量とデバッグ量、バグが入り込む余地を増やしました。

AJAXはエキスパート領域に感じられた

非同期リクエストは可能でしたが親しみやすくはありませんでした。XMLHttpRequestのセットアップには複数のステップ、ブラウザごとの分岐、レスポンス状態の注意深い取り扱いが通常必要でした。

フォームをページ遷移なしで送信するような小さな機能が、行数が膨らみ、再試行やエラー処理、ブラウザテストを含む作業に発展することがありました。

本当のコスト：信頼性とチームの生産性

最も大きな悩みはコードを一度書くことではなく、どこでも動くように保つことでした。チームは信頼できる、学びやすい、一貫性のあるものを必要としており、新しい開発者がブラウザ互換性のチェックリストを暗記しなくても貢献できる必要がありました。jQueryはその日常的な摩擦に対する答えとして現れました。

大きなアイデア：共通UI作業のための小さなAPI

jQueryの突破口はブラウザの新機能を発明することではなく、日常的なUI作業を考える新しい方法を示した点にあります。多数のブラウザ固有のJavaScriptを書いて要素を探し、更新し、イベントを結びつける代わりに、jQueryはその手順を「選択して、操作する」という単純なパターンにまで煮詰めました。

「見つけて、操作する」

中心にあるのは $() 関数です。CSSに似たセレクタ（または要素）を渡すと、マッチした要素をラップしたjQueryオブジェクトが返ります。

そこから、メソッドを呼んでタスクを実行します：クラスを追加する、要素を隠す、テキストを変更する、クリックハンドラを付ける。目的は低レベルな詳細をすべて晒すことではなく、ほとんどのサイトが必要とする80%のUI作業をカバーすることでした。

チェイニング：変数を減らし意図を明確に

jQueryはフルーエントなスタイルを推奨しました。各ステップが同じjQueryオブジェクトを返すため、一行でアクションを連結できます：

$(".notice")
  .addClass("active")
  .text("Saved!")
  .fadeIn();

内部を理解していなくても、物語は理解できます：通知を見つけ、アクティブにし、メッセージをセットして、表示する。

小さく一貫したAPIが重要な理由

jQuery以前、開発者は常に「このメソッドはどのブラウザで動くのか？」とか「古いバージョンではプロパティ名が違うのか？」と問うていました。jQueryは一貫したメソッド群と予測できる振る舞いでそれに答えました。初心者はブラウザのエッジケースに押し潰されずにJavaScriptに入門でき、プロはスピードを得ました：カスタムヘルパーの減少、互換性ハックの減少、レビューするコード量の削減です。

タスク志向のスクリプトが当たり前に

APIがコンパクトでメソッド名がUIの意図に直結していたため、jQueryはスクリプトを読みやすくしました。散らばったDOM呼び出しや一時変数の代わりに、UIアクションの連続としてコードを読むことができ、フロントエンド作業がブラウザと格闘するよりもステップを組み立てる感覚になりました。

セレクタとSizzle：「見つける」が簡単に

jQueryの説得力のある技の一つは、UI作業の最初の一歩である「適切な要素を選ぶ」ことを圧倒的に簡単にした点です。ブラウザ固有のDOMメソッドやその癖を覚える代わりに、CSSのような記述で一発で伝わるようになりました。

CSSセレクタという親しみあるモデル

デザイナーやフロントエンド開発者は既にセレクタという考え方に慣れていました：「ヘッダー内のすべての.buttonを取る」「特定のタイプの入力をターゲットする」「最初の要素を取る」。jQueryはこの思考モデルをJavaScriptツールに変えました：

• $(".nav a") でナビ内のリンクを操作
• $("#signup-form input[type=email]") で特定のフィールドを取得
• $("ul li:first") で簡単に「最初の項目」を扱う

読みやすさが重要で、欲しいことからDOMにどう尋ねるかへの翻訳コストを減らしました。

Sizzleがしたこと（そして重要だった理由）

$(selector)の背後にはSizzleという選択エンジンがありました。初期のブラウザは特定のセレクタの振る舞いで一致しておらず、フルセットをサポートしていない場合もありました。Sizzleは一貫した解釈とフォールバックを提供したため、$(".card > .title")のようなセレクタがブラウザによってばらけることがなくなりました。

結果として生産性が上がり、条件分岐や「もしIEなら…」といったワークアラウンドが減り、セレクタがあるブラウザでマッチして別のブラウザでマッチしない理由をデバッグする時間も減りました。

トレードオフ：便利さと隠れたコスト

セレクタの力はコストも隠していました：

• 高コストなセレクタはパフォーマンスに悪影響を与えることがある（スクロールやリサイズハンドラ内で繰り返し実行すると特に）
• 過剰に選択して後で直す、というパターンが増え、見た目は綺麗でも余計な仕事をしていることがある
• 複雑なセレクタに依存するとDOM構造に強く結びつき、壊れやすくなることがある

とはいえ、日常的なインターフェース作業で「見つける」が簡単になったのは大きな変化で、jQueryが強力に感じられた理由の一つです。

イベント、DOM変化、エフェクト：日常ツールキット

多くの開発者にとって、jQueryは「ライブラリ」以上の存在でした。インタラクションを作るときにまず手を伸ばす日常のツールセットだったのです。ブラウザが詳細で意見を異にしているときでも、いくつかの予測できる呼び出しで共通のUI作業を済ませられました。

ブラウザの驚きなしでのイベント

jQuery以前、クリックハンドラを取り付けるのはイベントモデルやエッジケースを扱うことを意味しました。jQueryの.on()（以前は .bind() / .click()）は、click、submit、キーボード入力などに一貫した方法でリスンする手段を与えました。

また「ページが準備できたら実行する」という習慣を明示しました：

$(function () {
  // safe to touch the DOM
});

この一つの習慣が典型的なページでのタイミングバグを減らしました。

暗記できるDOM操作

jQueryのDOM APIは意図的に小さく実用的でした。内容を更新するなら .text() や .html()、UIパーツを作るなら ('<div>...</div>') と .append()、視覚状態なら .addClass()、.removeClass()、.toggleClass() といった具合です。

className や属性の癖、ノードメソッドの不一致に悩む代わりに、開発者は「何を変えたいか」に集中できました。

インタラクションを“売る”エフェクト（ときに使い過ぎ）

.hide()、.show()、.fadeIn()、.slideToggle() のような組み込みアニメーションは、わずかな手間でページを活き活きと見せました。デザイナーはそれを好み、関係者はそれに気づき、チュートリアルもそれらを多用しました。

欠点は、効果を使い過ぎるとインターフェースが遅く感じられたり、安っぽくなることがある点です。それでもメニューやアコーディオン、通知のような典型的なインタラクションでは、jQueryは“きちんとした”見た目を手軽に実現しました。

イベント、DOM変更、エフェクトを通じて実際に得られたのは単純さでした：日常作業でのエッジケースが減り、チームが短期間で学べる共通パターンが生まれたのです。

AJAXを扱いやすく

jQuery以前、「AJAX」はトリックのように聞こえました：ページ全体をリロードせずに部分を更新すること。技術的にはブラウザがバックグラウンドでリクエストを送り、データを受け取り、ページを更新するだけです。

XMLHttpRequestからワンライナーへ

基礎は XMLHttpRequest ですが、直接使うと多くの繰り返しコードが発生しました：リクエストの生成、状態監視、レスポンス解析、ブラウザ差分の分岐など。

jQueryはその複雑さをヘルパーメソッドに包み、日常的な道具にしました：

• $.ajax()（細かく制御したい時）
• $.get() / $.post()（単純なリクエスト）
• .load()（HTMLを要素へ注入）

イベントハンドラを張り、クエリ文字列を組み、レスポンスを解析する代わりに、ユーザーに次に見せたいものに集中できるようになりました。

「モダン」に感じられた日常的な用途

これらのパターンはすぐに一般的になりました：

• 入力補完（タイプに応じて小さなリストを取得して表示）
• ページ遷移なしのフォーム送信（フィールドを送って成功やインラインエラーを表示）
• ダッシュボードの部分更新（ポーリングでテーブルやカウンタを更新）

サーバが旧式でも、jQueryによってインターフェースは応答的に感じられました。

人々がつまずいた点

jQueryはリクエスト開始を簡単にしましたが、正しく終わらせるのは必ずしも簡単ではありませんでした。よくあるミスは：

• 弱いエラーハンドリング：成功を前提にしてタイムアウトやサーバエラー、無効なJSONを無視する
• レースコンディション：複数リクエストの戻り順が入れ替わりUIを上書きする
• サイレントな失敗：ネットワーク切断時にユーザーへ何も知らせない

APIは開始のハードルを下げましたが、「ハッピーパス」だけで信頼できるインターフェースは作れないことを教える結果にもなりました。

プラグイン：jQueryの力を倍増させるエコシステム

jQueryは単にダウンロードするライブラリではなく、人々が上に構築するプラットフォームでした。プラグインはjQueryに新しいメソッドを追加する小さな拡張で、通常は $.fn にアタッチされました。開発者は同じスタイルで機能を呼び出せるため、機能を差し込むだけで済みました。

なぜプラグインは速く広まったのか

参入障壁が低かったことが大きいです。jQueryを知っていれば、既にプラグインパターンを理解していました：要素を選択し、メソッドを呼び、オプションを渡すだけです。

さらに、jQueryの慣習が異なる作者のコードであっても一貫性を感じさせました：

• 命名：$('.menu').dropdown() はネイティブjQueryのように読める
• チェイニング：良いプラグインは元のセレクションを返し、続けて操作できる
• オプションオブジェクト：設定は { speed: 200, theme: 'dark' } のように扱いやすい

プラグインが使われた場面

プラグインは生のDOM操作とフルアプリケーションフレームワークの「中間の欠けている部分」を埋めました。よくあるカテゴリはスライダー／カルーセル、フォームバリデーション、モーダル、日付ピッカー、オートコンプリート、ツールチップ、テーブルヘルパーなどです。

特にマーケティングサイトや管理ダッシュボードを扱うチームでは、プラグインを組み合わせることで数週間分のUI作業が一日で組み立てられるようになりました。

トレードオフ

プラグインブームには代償もありました。品質のばらつき、ドキュメントの薄さ、複数プラグインを組み合わせたときのCSSやイベント衝突、依存関係のスプロールが問題になりました。作者が離れてしまうとメンテされないプラグインがプロジェクトを古いjQueryに縛り付け、セキュリティや安定性のリスクになり得ます。

jQuery UIとjQuery Mobile：大衆向けコンポーネント

コアはDOM操作を予測可能にしましたが、チームは依然としてインターフェース部品を一から作る必要がありました。jQuery UIはそのギャップを埋めるもので、日付ピッカー、ダイアログ、タブ、スライダー、アコーディオン、ドラッグ／ソート機能などをクロスブラウザで動く形で提供しました。小さなチームやエージェンシーがマーケティングサイトや社内ツールを量産する際、その「十分に良い」価値は非常に魅力的でした。

jQuery UIが生産性のチートコードだった理由

ウィジェットだけでなく、一貫したAPIとテーマ化が組み合わさっていたことが大きな勝利でした。ダイアログやオートコンプリートを落とし込んで、ThemeRollerでブランドに合わせるだけでプロトタイプを素早く作れたため、毎回マークアップやCSSをゼロから作り直す必要がなかったのです。繰り返し可能性が高く、jQuery UIはデザインシステムというより実用的なツールキットに感じられました。

jQuery Mobileの賭け：混沌とした初期のモバイルウェブ

jQuery Mobileは別の問題に取り組みました。初期のスマートフォンはブラウザ能力が不安定でCSSサポートも限られ、レスポンシブ設計の慣習がまだ定まっていませんでした。jQuery Mobileはタッチに優しいUIコンポーネントとAjaxページ遷移による「シングルページ」ナビゲーションモデルを提供し、単一コードベースでネイティブに近い振る舞いを目指しました。

時代遅れになった理由

CSS3や改良されたモバイルブラウザ、ネイティブのフォームコントロールやレイアウトプリミティブが改善されると、これらの抽象はコストが大きくなることもありました。jQuery UIウィジェットは重く、アクセシビリティを確保しにくく、現代のデザイン期待に合わせるのが難しい場合がありました。jQuery MobileのDOM書き換えやナビゲーションモデルは、後のレスポンシブファーストやフレームワーク駆動のルーティングとぶつかることもありました。

それでも、両プロジェクトは再利用可能なUIコンポーネントが実地でいかに出荷速度を上げるかを示す重要な証明でした。

jQueryがフロントエンドコーディング習慣を変えた方法

jQueryはブラウザを扱いやすくしただけでなく、「普通の」フロントエンドコードの見た目を変えました。一般的なUIタスクが予測可能になったため、チームは特別なページだけでなく日常的にJavaScriptを書くようになりました。

フルーエントなAPIとチェイニング習慣

jQueryの文化的シフトの一つはチェイニングを一般化したことです：選択して操作を読みやすい流れでつなげること。

$(".card")
  .addClass("active")
  .find(".title")
  .text("Updated")
  .end()
  .fadeIn(200);

このスタイルは後続のライブラリや現代のネイティブAPIにも影響を与え、小さく構成可能な操作を好む方向に開発者を促しました。

「少ないコードで多くを」(とトレードオフ)

$.each、$.map、$.extend、AJAXショートカットなどのヘルパーにより、ロジックを短く書く誘惑が増えました。これは速度を上げましたが、しばしば「賢い」ワンライナーや暗黙の振る舞いを生み、後から読み返すのが難しくなることもありました。

多くのコードベースではビジネスロジックが直接クリックハンドラに混入しやすく、手早く出荷できる反面、後の複雑化を招きました。

直接DOM時代のテストとデバッグ

コンポーネントや予測可能な状態モデルが普及する前は、jQueryアプリは状態をDOM（クラスや隠し入力、データ属性）に置くことが多く、デバッグは生のHTMLを調べたりイベントコールバックを追うことが中心でした。ユニットテストは可能でしたが、チームは手動QAとブラウザのデベロッパーツールに頼ることが多く、バグはタイミングに起因する断続的なものになりがちでした。

jQueryコードがきれいに保たれた場合と絡まった場合

jQueryコードは次のような場合に保守しやすく保たれました：

• 影響を受ける要素の近くにDOMクエリを置く
• 小さな関数とイベント委譲を使う
• プラグインを再利用可能な部品として扱う

一方で、ページにハンドラが積み重なり、セレクタが至る所で繰り返され、アニメーションコールバック内で「あと一つだけ」と tweaks を重ねていくと絡まり始めました。ライブラリは高速な反復を可能にしましたが、結果が長く持つかどうかは規律次第でした。

なぜjQueryは衰えたのか：標準が成熟した

jQueryが一夜にして消えたわけでも、性能が落ちたわけでもありません。ブラウザプラットフォーム自体が通訳をほとんど必要としなくなったために利用が減ったのです。jQueryが平滑化していた問題――欠けているAPI、一貫性のない挙動、扱いづらいワークフロー――は標準化とブラウザの収束により少なくなりました。

ブラウザが良いところを取り入れた

DOMとJavaScriptのAPIが標準化されるにつれて、多くの通常のjQuery呼び出しにネイティブの同等物が現れました：

• 要素選択：document.querySelector() / document.querySelectorAll() が多くのケースをカバー
• イベント：addEventListener() が普遍的に信頼できる
• ネットワークリクエスト：fetch()（と async/await）がAJAX風の呼び出しをネイティブに読みやすくした

ネイティブの方法がブラウザ間で一貫すると、ヘルパーライブラリに依存する理由は小さくなります。

パフォーマンスとバンドルサイズの重要性が増した

Webアプリケーションがいくつかのインタラクティブウィジェットからフル製品へ成長するにつれて、ロード時間とJavaScriptコストがより重視されるようになりました。数行の便宜のためにjQuery（とプラグイン）を配布するのは、特にモバイルネットワークでは正当化しにくくなりました。

jQueryが遅いというよりは、「もう一つ依存関係を載せる」ことが現実的なトレードオフになったのです。開発者は小さく目的に特化したユーティリティ、あるいはプラットフォームが既に提供する機能を好むようになりました。

SPAはフロントエンド作業の意味を変えた

シングルページアプリケーションのフレームワークは、手作業でDOMを直接いじることから、状態を管理しコンポーネントからUIを構成する考えへと注目を移しました。React/Vue/Angularの考えでは、通常「ページに問いかけて要素を探して変更する」のではなく、データを更新してUIを再レンダリングします。

このモデルでは、jQueryの強みである命令的なDOM操作やエフェクト、ワンオフのイベント接続は中心ではなくなり、ときに避けるべき手法になります。

公平な見方：jQueryは成功しすぎて自らを不要にした

jQueryの使命はウェブを使いやすく一貫させることでした。ブラウザが追いついた結果、jQueryは必要性が減っていったのです。重要性が薄れたわけではありません。今でも多くのプロダクションサイトで使われており、多くの現代APIや開発者の期待はjQueryが教えた教訓に根ざしています。

レガシー：jQueryが残したもの

jQueryは新規フロントエンドでのデフォルト選択ではありませんが、驚くほど多くのウェブを静かに支え、その影響は多くの開発者のJavaScriptの考え方に刻まれています。

jQueryが今でも見つかる場所

主に次のような場所で出会うでしょう：

• jQueryの全盛期に作られ、まだ問題なく動いているレガシー業務アプリ
• 古いWordPressのテーマやプラグインなどCMS周り
• マーケティングページ上のちょっとしたスライダーやモーダルといった「クイック修正」スクリプト

これらを保守する場合の利点は予測可能性です：コードが理解しやすく、ドキュメントが多く、パッチを当てやすいことが多いです。

ライブラリを超えて残ったアイデア

現代のツールはjQueryをそのままコピーしたわけではありませんが、その優れた直感は吸収しています：

• 使いやすいAPI：いくつかの読みやすい呼び出しで一般的な作業を済ませる
• セレクタを中核概念に：「要素を見つけて、操作する」という発想
• 拡張性：プラグインマインドセットはパッケージエコシステムやコンポーネントパターンに引き継がれている

querySelectorAll、classList、fetch、改善されたイベント処理といったバニラJSの進化も、jQueryが日常開発者のために解決した問題を反映しています。

今日jQueryから学ぶべきこと

最大の教訓はプロダクト思考です：小さく一貫したAPIと優れたドキュメントは業界のコーディング方法を変え得ます。

また「開発者体験（DX）」は複利的に効くということの再確認でもあります。jQuery時代のDXはブラウザの癖を隠すことでしたが、今日のDXはアイデアから動くソフトウェアまでの道筋を短縮することを含みます。だから Koder.ai のようなチャットベースのプラットフォームが多くのチームに響くのです：ボイラープレートを手で組み立てる代わりに、チャットで反復し、Reactフロントエンド＋Go＋PostgreSQLのバックエンド（あるいはFlutterモバイルアプリ）を生成して前に進められ、必要ならソースコードをエクスポートしてフルコントロールに移行できます。

今の適切なツールの選び方

• 新規作業にはモダンなDOM APIやフレームワークネイティブのパターンを優先する
• 既存のjQueryコードは原則として書き換えない：リスクやコストが下がると確信できる場合に段階的にリファクタする
• 小さなワンオフUIには通常バニラJSで十分。すでにページにjQueryが読み込まれているなら実用的なショートカットとして使うのもあり

$(function () {
  // safe to touch the DOM
});