それなりブログ

とあるWebエンジニアのそれなりのブログ、JavaScript/Node.js/Python/PHP/ゲーム作成 など

RequireJSを使うのを止めた理由

RequireJS はみんな使ってるらしーし、
何かかっこいいし、意識高そうだし、使っとくか!

・・・と、思って試しに使い始めてみたのですが、
自分が作るような小規模なものの場合、
大変な割に良い事あんまりないので使うのを止めました。

以下、忘れそうなのでその理由をメモって置きます。

嫌だったところ

  • 基本的に、1枚のJSファイルが1モジュール、ファイル名がコードに影響する。それもあって、結合・圧縮は r.js という専用のツールが必要になる。Grunt の concat とか uglify とか使えない。
  • AMD の仕様では、「JSファイルのリストを順番通りに読み込み/実行する」ということができない。実際何が困ったかというと、分割した mocha テストケースを順番通りに実行できなくなったということ。結果は変わらなくても、順番通りに実行されないと結果が見辛いし、問題が起こった時に発見が難しい。ただしこれは、RequireJS の実装上は出来る
  • 上記は promise を返すようにすることで解決は可能でもある。ただ、そうすると今度は受け手側で promise なのかどうかを知らないといけなくなる。また、CUI から実行しようとすると、Web と node 両方で動く Deferred ライブラリを $.Deferred とは別に入れないといけない。これも Wスタンダードになるので微妙に気持ち悪い。
  • AMD に対応していないライブラリは、RequireJS 独自規格である shim で定義することになる。で、ほとんどライブラリが AMD 対応してない。
  • キャッシュ対策に使う requirejs.config の urlArgs が全ファイルに付いてしまう。個別に指定したかった。
  • 色々とダイナミックなことをしているのでソースを追う機会が多いが、ソースコードが難解で読むのが大変。

良いところ

  • 依存関係を明示出来る。
  • 必要なモジュールだけ読み込むことが出来る。多くのWebページで異なった構成のJSファイルを使ったり、1ページ=1JSファイル的なWebページを模したアプリを作るなら、ある規模以上からはほぼ必須だと思う。
  • モジュール単位で開発できるので、担当を分けたりするのに便利。
  • scriptタグを自動生成してくれる。

必要だから使うもの

自分の場合、「scriptタグ自動生成機能」だけ欲しかったので、
他の面倒さに全く見合わずに止めることにしました。
(後、勉強したかったというのもあって、それは満足した。)

もちろん、上記のように良いところはたくさんありますが、
特に Lazy loading の仕組みは、何かと影響範囲が大きいため、
「とりあえず入れる」のは止めるべき、というのが今の結論です。

まー、大規模開発なら、入れざるを得ない感じはしますが・・・。

オマケ: RequireJS の勉強に使った参考リンク



コメントを残す

メールアドレスが公開されることはありません。

Categories

Archives