2019年になってもまだjQueryを使用している理由

Post on:2019年6月5日

2019年になってもまだjQueryを使用しているのはなぜですか

多くの人が「普通のJavaScriptを使えば、jQueryは必要ない」と主張しています。私は多くを必要としないので、jQueryを必要としませんが、確かに便利です。

You might not need jQueryのようなページでは、jQueryを捨てるのは簡単だというアイデアを売り込もうとしていますが、逆にこのページの最初の例はjQueryを使用する正当な理由になってしまっています。例えば、1行の簡単なjQueryコードが、10行ものJavaScriptコードに置き換えられています。

JavaScrip APIの多く、特にDOM APIは美的感覚を損ねています。例えば、el.insertAdjacentElement('afterend'、other)はもちろん機能しますが、$(el).after(other)の方が実際には簡単です。私は$()関数（脚注1）のファンではありませんが、DOMが提供するものよりもはるかに優れていると思います。

ここでちょっと質問です。
要素の兄弟をどのように取得しますか？ nextSibling、またはnextElementSiblingですか？違いは何ですか？どのブラウザがどちらをサポートしていますか？
あなたがMDNでこれを確認している時間で、私ならjQueryのnext()とprev()を使用するでしょう。

標準的なJavaScript APIによる一般的な操作の多くは、扱いにくいです。ここでリストを挙げることもできますが、You might not need jQuery (YMNJQ)が逆にかなり良い仕事をしています。

ただし、さまざまな一般的なタスクにはヘルパー関数が必要です。繰り返しますが、YMNJQにそれらの多くがリストされています。jQueryを使用するのはこれらのヘルパーを含めるための標準的な方法で、必要なときに毎回Stack Overflowのランダムな答えからコピー＆ペーストする必要はありません。

ブラウザの互換性は以前ほど問題ではありませんが、それでも問題は残っています。特に「ブラウザシェアの85%で機能すればいい」と考えるのは、私にとってはかなりの大問題です。
参考: Why Hello CSS doesn’t use CSS variables

常にjQueryを使うべきでしょうか？いいえ、もちろんそうではありません。
依存性を追加するには複雑さとファイルサイズが犠牲になりますが、jQueryはそれほど大きくありません。デフォルトのビルドは30Kbで、AJAXや珍しいものを使わないカスタムビルドは23Kbです。そして、SizzleJSの代わりにquerySelectorを使ったビルドは17Kbです。オリジナルの30Kbと最適化された17Kbの両方とも、多くの目的のためにかなり許容できると私には思えます。

バニラJSを使うのにどれだけの労力を要するかの例として、BootstrapからjQueryを取り除いたv5 without jQueryが参考になります。彼らは独自のヘルパーを作成し、IEのサポートを追加するのが難しいためIEのサポートをやめなければならず、APIを互換性のないものにし(すべてを壊して)、一年半かけて取り組みました。最終的な結果を見ると、それがそれほど優れているとは言えません。

私は彼らがなぜそうしたのか理由を理解しています。「人々はVue.jsでBootstrapを使いたいと思っていますが、Vue.jsとjQueryの両方を使うのは馬鹿げています。」私はweb bloatを減らすことに非常に賛成です（こことここを見てください）、しかしわたし達は実用的で現実的である必要もあります。

17KbのjQueryを含めることは本当に悪いのでしょうか？ MediumやNew York Timesのようなサイトに1Mbを超えるJavaScriptが必要だと述べると、Webの情報通は「56kのラインで何かで立ち往生している？！」と防御的になります。jQueryの17Kbは、耐えられない重荷なのでしょうか?

jQueryを使用しない理由はいくつかあります。例えば、他の人に再利用されたいコードを書いている場合や、小さな関数を書いている場合です。しかし、jQueryを避けるために逆方向に曲げるのはどうでしょう? それだったら、jQueryを使用してください。「すべてをjQueryにする」はおそらく良い考えではありませんが、「すべてをunjQueryにする」も同じことです。

私はjQueryとは結婚しているわけではないので、喜んでJS APIにパッチを当てる「jQuery light」を使用します。YMNJQではbonzoと$dom、その他いくつかのAJAXを推奨していますが、多くは保守されていないようです。さらに、jQueryは誰もがすでに知っています。やむを得ない理由がない限り、なぜそれを別のものに置き換えるのでしょうか？

「Vue.js、React、またはその他最新のフレームワークはどうですか？」と疑問に思う人がいるかもしれません。この記事の目的は普通のJavaScriptとjQueryを比較することであり、フロントエンド開発の統一理論を提案することではありません。

とはいえ、普通のJavaScriptにこだわる理由はいくつかあると思います。高速で、最も簡単で実行可能なコードを使用し、できるだけ多くの人がアクセスできるWebページを構築したいからです。私の経験からすると、サーバーサイドで生成されたテンプレートに「プログレッシブエンハンスメント」スタイルのJavaScriptを少しだけ散りばめるのが、そのための最善の方法です。開発するのが簡単で、高速になり、バグも少なく、あなたのラップトップのファンは隣人の迷惑にならないでしょう。

これらのWebフレームワークが常に悪いということですか？
いいえ。「常に」悪い(または良い)ものはほとんどありませんが、一連のトレードオフがあります(もちろんjQueryも)。

基本的に、Webはドキュメントを見るためのシステムだと思います（OSよりむしろ）。多くのWebアプリ(それが何を意味するかにかかわらず)でさえ、ドキュメントによるアプローチは非常にうまく機能します(これは記事に値するトピックです)。