Zepto.jsが生まれた理由とjQueryとの違い

Zepto.jsは「jQueryの軽量版」ではない

Zepto.jsはよく「軽いjQuery」「モバイル向けjQuery」と説明されます。
確かにAPIは似ていますし、次のコードはそのまま動きます。

$("div").hide();

しかし、Zepto.jsはjQueryを縮小したものではありません。
結論から言うと、Zepto.jsは“jQueryが解決していた問題が消えた世界”を前提に設計されたライブラリです。

この違いを理解すると、なぜjQueryが巨大化し、なぜZepto.jsが小さくできたのかがはっきり見えてきます。

jQueryが背負っていた最大の仕事

jQueryの本当の役割はDOM操作の簡略化ではありませんでした。
最大の役割は「ブラウザ差異の吸収」です。

例えばイベント登録だけでも、かつては次のような差がありました。

ブラウザ イベント登録
IE attachEvent
標準ブラウザ addEventListener

さらに、

  • eventオブジェクトの構造が違う
  • targetとsrcElementの違い
  • preventDefaultの有無

といった問題がありました。

jQueryの.on()は、これらを全部統一しています。
つまり、jQueryのサイズの多くは「便利機能」ではなく互換処理でした。

スマートフォンの登場で状況が変わる

ここで大きな転換点が訪れます。スマートフォンの普及です。
iOS SafariとAndroid Chromeは、最初から比較的標準に準拠した実装を持っていました。

つまり、

  • attachEventが存在しない
  • 古いIEが存在しない
  • CSS実装の差が小さい

という環境になります。

このとき、jQueryの互換コードの多くが不要になります。
Zepto.jsはここに目を付けました。

Zepto.jsの設計思想

Zepto.jsは「互換性」を捨てています。
具体的には、古いブラウザをサポートしません。

  • IE非対応
  • 古いAndroid非対応
  • レガシーイベント処理なし

その代わり、ネイティブAPIをそのまま使います。

例えばDOM取得は内部的にquerySelectorAllを使用しています。
jQueryはブラウザごとに異なるセレクタ挙動を補正していましたが、Zepto.jsは補正しません。

つまり、Zepto.jsは“標準が信用できる”前提で作られているのです。

サイズが小さい本当の理由

Zepto.jsが軽い理由は最適化ではありません。
互換処理を持たないからです。

ライブラリ サイズの主な内訳
jQuery 互換コード + API + イベント正規化
Zepto.js APIのみ

たとえばイベントオブジェクト。
jQueryではブラウザ差を吸収するためラップされていますが、Zepto.jsではネイティブイベントがそのまま渡されます。

これは軽量化の代わりに、環境依存が増えるというトレードオフです。

API互換なのに完全互換ではない理由

Zepto.jsはjQuery風に書けますが、同じではありません。
典型的な違いはAjaxです。

$.ajax({
  success: function(data){}
});

一見同じですが、細かな挙動が異なります。
また、jQuery特有のDeferredや一部のエフェクトは存在しません。

このため、PC向けサイトのjQueryコードをそのまま移植すると動かないことがあります。
「軽量jQuery」と考えて置き換えると、現場でトラブルになります。

なぜZepto.jsは広く置き換えなかったのか

技術的には合理的でも、普及には別の条件が必要でした。
企業のサイトでは、依然として古いブラウザのサポートが求められていました。

つまり、

  • PCサイト:jQueryが必要
  • モバイル:Zepto.jsで十分

という分断が起きます。
この状況では、開発者は両方を覚える必要があります。結果としてjQueryを使い続ける方が安全になりました。

その後の変化

さらに時間が進むと、状況はもう一度変わります。
ES5/ES6の普及です。

querySelector、classList、fetchなどのAPIが一般化し、「ライブラリを使わず書ける」領域が増えました。
この時点で、jQueryとZepto.jsの差は小さくなり、どちらも必須ではなくなります。

最後に

Zepto.jsはjQueryの後継ではありません。
jQueryが作った「互換レイヤー」という役割が不要になった世界の実験的ライブラリでした。

言い換えると、Zepto.jsの存在そのものが、ブラウザ標準の成熟を示していたと言えます。
jQueryが問題を解決し、Zepto.jsがその解決の終了を示した――この順番で理解すると、フロントエンドの進化がとても自然に見えてきます。