jQuery

jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの

More than 3 years have passed since last update.

俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな…


基本的な方針

とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。

ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。

Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。

また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていない、ということは十分にありえます。

React 127k, jQuery 120k, underscore 42k みたいな世界なので、両方入れるのは嫌だな、といった具合です。ちょっとしたライブラリなのにjQuery依存あって全体に +127k となるのは嬉しくない。


You Don't Need jQuery を読みなおしてわかること

You Don't Need jQuery - Qiita のコメントは「生DOM操作は冗長なコードが多く、jQuery の良さを再確認した」という意見が多かったですが、↑の記事をよく読むと分かるのですが、冗長な部分は「座標計算」、「親方向の探索」に多いです。

$.fn.heght/width/offset/position/scrollTop その辺の「座標計算」の複雑さは、というかGUIの座標系は本質的に面倒くさいです。とはいえ、jQueryの本来の用途であるDOM操作の本質からはやや離れます。

「親方向への探索」はそもそもViewのモジュラリティを破壊するコードで、行儀が悪いコードだと思います。closest/sibling/next/prev 等を乱用したコードを想像してみてください。やっつけで書かれたjQueryで、Webエンジニアなら発狂したことはないですか?これらが標準機能として提供されない意図は、ライブラリ提供する側としては、理解できるでしょう。


本当に必要だったものは document.querySelector

結局、基本的にほとんどの人が必要としたのは document.querySelctor/document.querySelectorAll なんじゃないでしょうか。それに付随して頻出する操作は、 $.fn.css$.fn.attr を対応するプロパティへ置き換えるだけで、これらはアクセッサが違うだけで、難しいとは聞いたことがありません。


座標計算系の難しさ

画面設計で僕もよく連立方程式を解いたりしてるんですが、ブラウザで値がぶれたりすると非常にデバッグが面倒です。これらを吸収してくれるjQueryは確かに助かります。

jQuery本体の以下のコードを読んでみてください。涙ぐましい努力が滲んでいます。

とはいえ、決定版といえる座標系ライブラリがないので妥協してjQuery使ってるだけで、将来的には僕も非推奨だと言ってる可能性が高い気がします。


jQueryのセレクタを使う場合は下方向の探索(find)のみを使う

closest や sibling の親・兄弟への探索は複雑なので、jQuery どうこう以前に、集団開発では避けたほうがいいです。僕は自分以外がclosest/sibling使って書いてたら基本的に読むのは諦めてスクラッチします。

僕がjQueryセレクタを使う場合は、基本的にコンポーネント要素のルートからの find のみとしています。DOMの相対座標に依存したコードは、とにかく変更に弱く、改修も困難です。頼む、やめてくれ。40000行のbackboneを管理した経験からそう言っています


結論

座標系は難しい