昔のJavaScriptがブラウザごとに動かなかった理由とjQueryの役割

なぜ昔のJavaScriptはブラウザごとに動かなかったのか

かつてのWeb開発では「JavaScriptを書けば動く」という前提がありませんでした。
同じコードを書いても、Chromeでは動き、Internet Explorerでは壊れ、Firefoxでは挙動が違う、ということが日常的に起きていました。

これはJavaScriptの仕様が未成熟だったからではありません。
問題の本質は“ブラウザがJavaScriptをどう実装していたか”にあります。

現在の私たちはECMAScriptという共通仕様の上で開発しています。しかし2000年代前半、ブラウザ各社は互換性よりも自社機能を優先していました。
つまり「同じ言語を使っているが、別の実行環境」だったのです。

この状況を理解すると、jQueryの役割が単なるライブラリではなかった理由が見えてきます。

DOMという最大の不一致

DOMは共通規格だったが共通実装ではなかった

WebページはHTMLで構造を持ちます。
JavaScriptはその構造、つまりDOM（Document Object Model）を操作します。

理屈の上では、DOMはW3Cが定めた共通規格です。
しかし問題は「仕様」と「実装」は別物だったことです。

たとえば要素の取得です。

document.getElementById("title");

現在では当然動きます。
しかし当時のInternet Explorerでは次のコードも存在しました。

document.all["title"];

IEは独自DOMを持っていたため、開発者は両方に対応する必要がありました。

var el;
if (document.getElementById) {
  el = document.getElementById("title");
} else if (document.all) {
  el = document.all["title"];
}

つまりJavaScriptを書くというより、
ブラウザ判定コードを書く作業が大半だったのです。

イベントモデルの違い

イベント処理はさらに深刻でした。
同じクリックイベントでも登録方法が違います。

element.addEventListener("click", handler, false); // 標準
element.attachEvent("onclick", handler); // IE

引数の順番、イベントオブジェクト、thisの参照先まで異なります。
同じイベント処理でも2種類のコードを書く必要がありました。

しかもイベントバブリングの挙動も違います。
フォーム送信、リンククリック、キーボード入力など、UIの基本操作すべてに影響しました。

CSS操作も統一されていなかった

スタイル変更ですら共通ではありません。

element.style.opacity = "0.5"; // 標準
element.style.filter = "alpha(opacity=50)"; // IE

透明度ひとつ変えるだけで分岐が必要でした。
さらにボックスモデルの解釈も異なり、要素サイズの計算結果が変わる問題もありました。

つまり当時のフロントエンド開発は「レイアウト調整」ではなく
ブラウザの癖を相手にする作業でした。

Ajaxの互換性問題

特に大きかったのがAjaxです。
非同期通信はWebアプリの基盤ですが、これも統一されていませんでした。

var xhr;
if (window.XMLHttpRequest) {
  xhr = new XMLHttpRequest();
} else {
  xhr = new ActiveXObject("Microsoft.XMLHTTP");
}

さらに、

• readyStateの監視
• ステータスコード判定
• 例外処理

を自前で書く必要がありました。
開発者はビジネスロジックではなく、通信の互換性に時間を費やしていました。

ここで登場したjQueryの役割

jQueryは新しいAPIを作ったわけではありません。
既存APIの差異を1つの書き方に統一しました。

要素取得はこうなります。

$("#title");

イベント登録はこうです。

$("#btn").click(handler);

Ajax通信も同様です。

$.ajax({
  url: "/api",
  success: function(data){
    console.log(data);
  }
});

開発者はブラウザ判定を書かなくてよくなりました。
これがjQueryの本質です。

jQueryは「機能」ではなく「翻訳層」

重要なのは、jQueryが特別な機能を提供したわけではない点です。
DOM、イベント、Ajaxはもともとブラウザに存在していました。

jQueryがしたことは、
ブラウザごとのAPIを共通言語に翻訳したことです。

いわばOSのドライバのような存在です。
ハードウェア差を隠すことで、開発者はアプリケーションに集中できるようになりました。

なぜ急速に普及したのか

普及の理由はシンプルです。

• コード量が激減した
• デバッグ時間が減った
• IE対応が容易になった

特に企業サイトではInternet Explorer対応が必須でした。
jQueryは互換性対策コストを大幅に下げました。

ライブラリの導入というより、
品質保証の手段として採用されたのです。

注意点 ― jQueryが必要なくなった理由

現在では次が普通に使えます。

document.querySelector("#title");
fetch("/api");
element.addEventListener("click", handler);

つまりブラウザ自体が互換性を持ちました。
jQueryが解決していた問題が、標準仕様として解決されたのです。

そのため「jQueryは不要」と言われるようになりましたが、正確には
役目を終えたと言う方が近いでしょう。

まとめ

昔のJavaScriptがブラウザごとに動かなかった理由は、言語仕様ではなくブラウザ実装の分裂でした。

jQueryは

• DOM差異の吸収
• イベントモデルの統一
• Ajaxの簡略化

を実現し、Web開発を初めて安定させました。

現在のフロントエンド開発が「当たり前に動く」のは、
過去に互換性問題と戦ったライブラリが存在したからです。

jQueryは過去の技術ではなく、
現代Web標準の前段階だった技術と考えると理解しやすいかもしれません。