RequireJSを使うのを止めた理由
2013年7月16日
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 の勉強に使った参考リンク
あざざざざざざざざーす!
- [Javascript] Require.js を使ってみる
- RequireJSにてBackbone.jsとMustache.jsを読み込む
- [JS] RequireJSのオプションで良く利用するBaseUrl, Paths, Shimを学ぶ
- requirejsのconfigを調べてみた
- RequireJS と mocha を一緒に使う (init の使い方)
- CommonJS AMDとDeferred
- require.js の require関数が同期的に動く理由
- timrwood/moment (CommonJS/AMD/windowマルチ対応のExports例)
- Re: RequireJSを使うのを止めた理由 (勉強になった、けどもうしばらく封印)