俺も昔はお前のような 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本体の以下のコードを読んでみてください。涙ぐましい努力が滲んでいます。
- https://github.com/jquery/jquery/blob/master/src/dimensions.js
- https://github.com/jquery/jquery/blob/master/src/offset.js
とはいえ、決定版といえる座標系ライブラリがないので妥協してjQuery使ってるだけで、将来的には僕も非推奨だと言ってる可能性が高い気がします。
jQueryのセレクタを使う場合は下方向の探索(find)のみを使う
closest や sibling の親・兄弟への探索は複雑なので、jQuery どうこう以前に、集団開発では避けたほうがいいです。僕は自分以外がclosest/sibling使って書いてたら基本的に読むのは諦めてスクラッチします。
僕がjQueryセレクタを使う場合は、基本的にコンポーネント要素のルートからの find のみとしています。DOMの相対座標に依存したコードは、とにかく変更に弱く、改修も困難です。頼む、やめてくれ。40000行のbackboneを管理した経験からそう言っています
結論
座標系は難しい