jQuery不要論について考える

　jQueryは、長らくWeb開発の現場に君臨し、その発展を助けてきたJavaScriptフレームワークです。今回は、最近巷で囁かれている、「jQuery不要論」について考えてみたいと思います。

jQueryとは

　古来、JavaScriptの実装がブラウザによって異なり、全てのブラウザ（特にIE）に対応しようとすると、その労力は計り知れないものでした。

　そのブラウザ間の差異を吸収する選択肢のひとつがjQueryで、登場以来多くのプロジェクトで採用されることとなります。

　また、コーディングが短く、簡潔になることも特徴のひとつで、生産性の向上に大きく寄与してきました。

// native javascript
document.getElementById("element");

// jQuery
$("#element");

　しかし、時代が進むにつれ、JavaScriptの標準仕様も広く浸透し、ブラウザによって挙動が全く変わるなどという現象もあまり見られなくなってきました。

　そこで、古くから慣れ親しんだjQueryから脱却しようという声も、多数上がってくるようになりました。

jQuery不要論

　まだまだプロジェクトで使われることも多いjQueryですが、速度的な問題や、実装に手間のかからないネイティブメソッドの存在もあり、年々不要論は強くなってきています。その理由を考えてみましょう。

代替可能なネイティブメソッド

　元々、jQueryに搭載されていたメソッドは、その殆どがネイティブメソッドで賄えるようになりました。代表的なものは、セレクタメソッドでしょう。

// jQuery
$("#element");

// native javascript
document.querySelectorAll("#element");

　jQueryのセレクタ記法（厳密に言うとCSSですが）がそのまま使えてしまいます。

　たとえば以下のようにすると・・・

// native javascript
var $ = document.querySelectorAll;
$("#element");

　jQueryとまったく同じコードが出来上がりました。（もちろん、戻り値はjQueryオブジェクトではありません）

　他に、eachメソッドでは・・・。

// jQuery
$([1, "two", "three"]).each(function(i, o){
    console.log(o);
});

// native javascript
[1, "two", "three"].forEach(function(o){
    console.log(o);
});

　forEachというネイティブメソッドがArrayに実装されています。

jQueryのファイルサイズ

　重い、重いと言われているjQueryですが、実際のサイズはどうなのでしょうか。

1.12.4.min	2.2.4.min	3.1.1.min	3.1.1.slim.min
94.8 KB	83.5 KB	84.6 KB	67.6 KB

　なるほど、確かに重いですね。

　さて、ページの表示時間でよく話題に上がる数字が、「2秒」です。これを超えると、ページのパフォーマンスが悪いとみなされるようです。

　それでは、ページの表示速度について特に重要だとされるモバイル環境の速度を考えてみましょう。

　この辺を参考に速度を抜き出し、一番重い94.8KBのjQueryをダウンロードした場合の速度を計算してみます。

　まず、94.8KBをKbitに変換します。簡略化のため1KB＝8Kbitとして計算すると、758.4Kbitとなりました。これが基準です。

　では、それぞれ何秒かかるか見てみましょう。

128kbps（速度制限）	1.97Mbps（3G）	11.51Mbps（4G）
5.96sec	0.38sec	0.06sec

　速度制限時は論外にしても、0.4秒…はギリギリ気になるか気にならないかのラインですね。4G(LTE)であれば殆ど無視できると思います。

　ネットワーク回線は、今後もどんどん高速化していくことが予想されますから、そこまで神経質になる必要は無いと思います。何なら、モバイルや低速回線向けのページやロジックを別で用意してもよいのです。

　最近では、ページの表示速度を何よりも重視した、AMP（Accelerated Mobile Pages）などの技術も導入されていますね。

　ところで、１ページごとの平均総容量が気になったので調べてみました。

　httparchive.orgによると約2,500KBですから、jQueryは単純にその25分の1程度です。128kbps回線だと3分ほど待たされます。おそろしい。

jQueryは動作が重い

　複数のブラウザに対応するため、jQueryでは、いくつものブラウザ判定や分岐が行われています。これが昔は「必須」とまで言われた所以であり、そして現在「不要」と言われている原因のひとつでもあります。

　昔と違って現代のフロントエンドでは、Chrome、Firefox、Safari、Edgeの4種が大きな勢力を保っています。仕様からの逸脱や、ブラウザ独自実装の動作などの心配も殆どなくなってきました。

　であれば、必要のない処理をしているjQueryを使えば、当然その分がオーバーヘッドとなり、遅くなることは仕方のないことなのです。（ブラウザの判定や、jQueryオブジェクトの生成など・・・）

jQueryは本当に不要か？

　確かに、先ほど述べたように、現代のフロントエンド開発においては不要になってしまったのかもしれません。しかし、多彩なDOM管理、変更のメソッドを持つjQueryは、ネイティブJavaScriptを記述するよりも遥かに短く、簡潔な記述が可能です。

　例えば、CSS（Style要素）の変更を例に挙げてみましょう。ここでは、.colorableというクラスがある要素が複数あるものとします。

　jQuery

$(".colorable").css({
    "color": "red"
});

　Native

document.querySelectorAll(".colorable").forEach(function(element){
    element.style.color = "red";
});

　ネイティブJavaScriptでも、forEachなどのメソッドを駆使することで非常に簡潔な記述が可能になっていますが、それでもjQueryの簡潔さには及びません。

　そもそも、フレームワークとは、内部処理を隠蔽し、新たなAPIを与えることで、コーディングにある一定のルールを課すとともに、効率的なプログラミングを行うことを目的として考えられるものです。

　回線速度の高速化、端末の処理速度の高速化などの恩恵を受け、メモリの心配をする必要もなくなってきました。

　それに逆行し、処理速度を追い求めることは、必要な場合を除き、自己満足以外の何ものでもありません。処理コストよりもコードの読みやすさが重視される風潮は、もう何年も前から続いています。

jQueryを使うべきか否か

　難しい判断になります。プロジェクトの方針によりますが、ネイティブJavaScriptでのDOM操作よりもjQueryに精通しているフロントエンドエンジニアは珍しくありません。JavaScriptでのDOM操作を調べているのに、jQueryを利用してのDOM操作しか検索結果に表れない…、などの経験は、フロントエンドエンジニアに限らず、JavaScriptを触る多くの人が経験したことでしょう。

　こういったメンバーが多い場合、ネイティブJavaScriptをガリガリ書くよりも、jQueryを導入したほうが遥かに素晴らしい結果となります。

　現在はAngularやreactなどの優れたフレームワークがいくつもあります。こういったフレームワークがDOM操作を代行してくれるのであれば、あえてjQueryを使う必要は無いのかもしれません。しかし、こまやかなエフェクトやDOM操作が必要となったとき、ライブラリを内製で自作するコストを考えれば、jQueryを導入することを躊躇う必要はありません。

処理速度の難

　jQueryは、様々なメソッドをラップしたライブラリですから、どうしても速度面で難はあります。速度にシビアな対応が求められるシステムでは、jQueryを使うことは推奨しません。全てネイティブJavaScriptで記述するべきです。

　ただ、このような性能要件を求められるプロジェクトが一体どれだけあるのでしょうか。モバイル向けを重視したWebサイトであれば、もちろん処理速度は重要でしょう。しかし、現代の端末性能を考慮すると、通常のWebページのレンダリングにjQueryを利用していたところで、特殊な処理を除き誤差の範囲（人間が知覚できない程度）の性能差しか得られません。

　システムは常にユーザーの立場に立って考えるべきです。「JavaScriptの総処理速度が50msから5msに短縮しました！」と聞くと、エンジニアからすれば確かに素晴らしいものですが、実際にページを閲覧する側からすれば誤差にすぎません。やってしまいがちですが、これは技術者サイドの自己満足になってしまいかねません。

ライブラリの重さ

　これは、ブラウザキャッシュの活用や、gzipなどの圧縮技術を使うことで解決を図れます。確かに、モバイル端末からのアクセスで100kb弱のライブラリのダウンロードを強いるのは、とても気になることかもしれません。しかし、ブラウザキャッシュとgzip圧縮などの技術を適切に活用すれば、特に気にする必要は無くなるはずです。

　下記はnginxの例です。

# gzip
gzip on;
gzip_types text/javascript;

# expire
expires 7d;

　これで、gzip圧縮かつ、1週間はブラウザキャッシュされたファイルが読み込まれます。そうすると、ページ表示速度への懸念は更に少なくなります。

結局、使うべきなの？

　jQueryを導入することによって様々な課題が解決できるでしょう。しかし、こればかりはケースバイケースと言わざるを得ません。プロジェクトによって実現すべき要件・要求は多岐にわたりますから、一様にjQueryを導入すべきという回答はあり得ないことです。

　しかし、ごく一部でもjQueryを使うことで素早く解決できる問題があるのだとすれば、jQueryを使うことに躊躇う必要はありません。それがJavaScriptフレームワークのAngularやreactなどを使っていた場合だとしても、使い慣れたjQueryが必要だと感じたなら、迷わず導入を検討するべきです。

　ただし、DOMを直接操作するjQueryと、ShadowDOMや仮想DOMを扱うangular、reactはお世辞にも相性が良いとは言えません。これらのフレームワークを使用している場合は、どうしても使いたいjQueryプラグインがあるなど、特別な場合に限定すべきかもしれません。もしくは、その危険性を充分理解した上で使うべきです。

　脱jQueryの風潮もありますが、jQueryを使うことによるメリットが少しでも勝るなら、使うことを遠慮する必要はありません。

　結局のところ、jQueryを使うか、他の代替技術を使うかはプロジェクトの意向に委ねられていると言えます。

まとめ

　技術に限らず、あらゆる物事には盛衰があります。jQueryは、衰えている最中なのかもしれません。

　おそらく、もう数年もすれば、フロントエンドはES6を使用した開発に切り替わることでしょう。しかし、現在におけるJava8の普及状況に鑑みると、ES6がフロントエンドに完全に浸透するまでは、また暫くの時間が掛かりそうです。

　jQueryがフロントエンド開発の現場から退場するのは、もう暫く後なのかもしれません。