見つけた便利MV**ライブラリを紹介するときにjQueryをスケープゴートにするのをいい加減に止めろ

javascript

オレオレMV**フレームワークを紹介する際にjQueryを引合いに出して語る事案が多く、そこで語られるjQuery批判が的外れもいいところなのが散見されるので書きました。

Abstract

  • MV**便利フレームワーク・ライブラリを紹介するときに、jQueryの一番イケてない書き方を引き合いに出して比較して「こんなにすごいんです」と紹介するのは不毛極まりないのでいい加減に止めろ
  • jQueryで書いたコードがひどいのは、クライアントサイドWeb（あえてこう書く）が過去10年近くにわたって設計を軽視してきた結果であり、その根本が変わらない限り、問題は変わらない
  • jQueryエンジニアをdisりながら、Angularエンジニアを産み出すとかギャグじゃないの？

私個人のjQueryに対する見解

だいたい同意する意見：

上に挙げられている意見に限らずとも、

  • jQuery.each()に渡すコールバックに渡される引数はjQueryオブジェクトではなく生のDOMオブジェクト
  • jQuery.Deferredはdeferredとpromiseという二種類の類似概念が提供されている
  • なんでもありのメソッドチェーン推奨機構
  • jQuery.parseHTML()がDocumentFragmentではなくリストを返す
  • クエリで取得した要素集合が空であってもエラーを発生させないので、デバッグが著しく困難
  • 可変長引数ベースのAPIかつ公式のドキュメントが読みにくいので使い方理解するのも面倒くさい（IDLほしい）
  • プラグインを名乗るクソコードの山というエコシステム
  • thisのコンテクストを考慮していない、関数渡しのみのAPI設計
  • 実行されたクエリセレクタのコンテクストに深く依存した便利メソッドの数々

などなど、DOM操作基盤ライブラリとして、自分の足や同僚の背中をいともたやすく撃ちぬくことが可能な実にじゃじゃ馬なAPI群であり、扱いにくくて仕方ないですが、その一方で

  • IE6~最新のブラウザまで包含した、DOM Event Modelもどきを提供するwrapper機構
    • jQuery 1.7でjQuery.on()が追加されたことでその傾向が強まった
  • jQuery()に対してセレクタ文字列を渡すことで、Document.querySelectorAll()相当の寄稿として用いることができる
  • 要素集合を自分でイテレーションせずとも、find()などで各要素の子孫の集合を一発で取得できる
  • 基盤ライブラリとして普及しているがゆえに、導入するケースが多く、導入さえすればDeferred/Promiseモデルを簡単に導入できる
  • 面倒くさいアニメーション処理を簡単に記述できる

といった点は、IE6~8へのサポートを実施する必要があった時代に於いては救世主のような機能であり、今なお色褪せることはないものだと思います。

こうした事実を踏まえ、「扱いが難しく、洗練されたAPIモデルではないが、うまく取り扱えば非常に有用性のあるライブラリである」というのが私の認識です。

最新のイケイケMV**フレームワークの引き合いに出される「これはひどい」jQueryのコードについて

酷い場合だと以下のようなコードが例に出されると思います。

$("#hoge").find("a").each(function(i){
    var bar = function () {
      $("foo").replaceWith("aa");
    };
    $(this).mouseover(function(){
      bar(i); 
    }).mouseout(function(){...}).parent()
      .closest().focus(function(){}).appendTo("aaa");
});

これはやり過ぎですが、こんなのjQuery関係なくクソコードに決まってるだろうが！

このようなコードを例に出して藁人形メソッドでjQueryを貶めるのはやめるべきだ。ライブラリ比較を通じてjQueryを批判するべきは、そのAPIモデルの一貫性の無さであり、コーディングスタイルそのものは、そんなクソコードを書いたエンジニアの仕事ぶりに責任の一端がある（別に人格批判しろって意味じゃないです）。

考察: jQuery == クソコードの代名詞はなぜひろまったのか

推論ではありますが、jQueryがクソコードの代名詞のように言われるようになったのは、単純にそれを使うエンジニアが設計を蔑ろにしてきてしまったツケが理由でしょう。プログラマ用語っぽく言えば負債です。

jQueryが流行った当時は、AjaxでクライアントサイドJavaScriptが花開いたものの、一部を除いて、ほとんどがUIウィジェット程度のものであったがために、ついつい書き捨てで済ましてしまっていたことが一つ。もう一つは、jQueryのAPI自体があまりにも暴発しやすいものであったが、シンタックスシュガーとしてついつい便利に使ってしまったり、中二病のようにメソッドチェーンや短いコードに拘泥した結果、あたかもそれがライブラリの唯一無二の正しい利用方法として定着してしまった結果なのではないでしょうか。

これから考えるべきこと

ここまで書いて、なんかやる気無くなってきたので雑に書くと：

  • 設計ちゃんと考えるべき
  • そもそもそれはライブラリの問題なのか、書き方の問題なのかを考えるべき
    • jQueryも単にDOMラッパーとして使うだけであれば非常に有用である
      • Abstractionであり、そこにロジックをひもづけてはいけない。ロジックはもっと上位の階層で考えるべき

最後にjQueryについて

jQueryのAPIモデルやっぱり汚いので、Well-madeなDOM互換ライブラリができるか、IE8~9以前すべて絶滅してほしい