jQueryとPrototype.jsの思想の違いを解説 - Web開発における知見共有系ページ

jQueryとPrototype.jsは、どちらもDOM操作を簡単にするJavaScriptライブラリとして語られがちです。
しかし実際には、同じ問題を解決しようとしていたにもかかわらず、設計思想はほぼ正反対でした。

結論から言うと、Prototype.jsは「JavaScriptを改良するライブラリ」、jQueryは「JavaScriptをラップするライブラリ」です。
この違いが、その後のフロントエンドの方向性を大きく分けました。

Prototype.jsは、既存のJavaScriptを使いやすくするために、標準オブジェクトへ直接メソッドを追加する設計を採用しました。

例えば次のようなコードです。

"hello".capitalize();

通常のJavaScriptには存在しません。しかしPrototype.jsを読み込むと動きます。
なぜかというと、String.prototypeにメソッドを追加しているからです。

String.prototype.capitalize = function(){
  return this.charAt(0).toUpperCase() + this.slice(1);
};

配列、文字列、オブジェクトなど、ほぼすべてのネイティブオブジェクトに拡張が加えられます。

この設計のメリットは明確です。

つまりPrototype.jsは、JavaScriptを別の言語のように作り替えようとしたライブラリでした。

一方、jQueryは正反対の方法を選びました。
ネイティブオブジェクトを変更しません。代わりに「ラッパーオブジェクト」を作ります。

$("p").hide();

$("p")はDOMそのものではなく、jQueryオブジェクトです。
jQueryはDOMやブラウザAPIを直接触らず、すべてを自分のオブジェクト経由で操作させます。

この設計により、

という特徴が生まれました。

当時、複数のライブラリを同時に使うと頻繁に問題が起きました。
Prototype.jsもjQueryも、どちらも$を使います。

Prototype.jsでは、$はDOM取得関数でした。

var el = $("menu");

一方jQueryではセレクタです。

var el = $("#menu");

両方を同時に読み込むと、後から読み込んだ方が$を上書きします。
この問題が実際の現場で大きなトラブルになりました。

jQueryはこれに対し、noConflictという仕組みを用意します。

jQuery.noConflict();

これにより、$を使わずjQueryだけを安全に利用できました。
ここにも「既存環境を壊さない」という思想が表れています。

Prototype.jsが劣っていたわけではありません。むしろ当時としては非常に先進的でした。
しかし、設計上の問題を抱えていました。

最大の問題は「ネイティブ拡張」です。
標準オブジェクトを書き換えると、ブラウザ仕様の進化と衝突します。

例えば後年、ECMAScriptに同名のメソッドが追加されると、挙動が変わる可能性があります。
さらに、別のライブラリが同じ名前のメソッドを追加すると競合が発生します。

つまり便利な反面、アプリケーション全体に影響が及ぶリスクがありました。

jQueryが広まった最大の理由は「安全性」です。

企業の大規模サイトでは、複数チームが同時に開発します。その環境では、言語仕様を書き換えるライブラリは扱いが難しくなります。

jQueryは既存コードに影響を与えず導入できました。
この「途中から入れられる」性質が決定的でした。

両者の違いは、書き心地にも現れます。

Prototype.jsは、JavaScriptを理想的な言語に近づけようとしました。
jQueryは、現実のブラウザを扱いやすくすることに集中しました。

つまり、

と言えます。

この違いは、後のフレームワークにも影響を与えました。
現在主流のライブラリの多くは、ネイティブを変更せずラッパーや仮想DOMを使います。これはjQueryの系譜です。

jQueryとPrototype.jsは競合製品ではなく、Web開発の方向性を示す分岐点でした。
JavaScriptを改造するか、ブラウザを扱いやすくするか。その選択が、後のエコシステムを決定づけました。

結果として主流になったのは後者でした。
jQueryは新しい言語を作らなかった代わりに、既存の環境の上で確実に動くことを優先したライブラリだったのです。