「Node.js楽園の問題：npmという混沌」
Drupal・DjangoからNode.jsに移ったが開発者がnpmモジュールの氾濫問題を指摘している：
http://mikkel.hoegh.org/blog/2011/12/20/trouble-in-node-dot-js-paradise-the-mess-that-is-npm/
CSSやJavaScriptなどのアセットを圧縮してくれるモジュールが必要だったので調べてみたら、(推定)100を越える候補が出てきた。 管理されていないものを除外するなどの一次選択のふるいにかけても26の候補。(リストは元記事参照)
Djangoなら明かな候補(asset-managers)があるのにNode.jsだと数十の候補を検証しなければいけない。このような時間をさくぐらいなら、自分で書いた方が速いと困惑している。
アセット管理だけでなく、routing、テンプレート、テストなど、Node.jsの各分野にこの問題は存在すると指摘している。
最後に自分のバージョンを作る前に既存のものを評価して、そこに貢献するようにと呼び掛けている。
このポストは面白い問題を提起している。混沌とするエコシステムの是非。解決法は何か？
ではどうしてこのような問題が発生したのか。
Node.jsの異例の勢い
実行環境数が世界一でありる言語がにわかにサーバ側で使用可になった特殊な状況が背景にある。言語は細やかに始まり、そのウェブスタックもそれと一緒にゆっくり成長していくのが一般的だ。JavaScriptにおいては、長期にブラウザのなかで育てられ、いきなりサーバ側に開放された形になった。たまっていたプレッシャーによって一気に広まった感じだ。
GitHub革命
Node.jsの出現とコードのソーシャル化が重なったのが爆発的な成長のもう一つの要因だろう。GitHubはブログのように気軽にコードを公開することを当たり前にしてしまった。悪く言うと猫もしゃくしもモジュールが貢献でいるようになった。これだと、思い付きでやった週末プロジェクトと真剣なものがスペースを共有していて見極められない。
上の記述で実感が湧かない人はCPANやpypiへの貢献とGitHubでの公開を比較してみるといい。前者の方が多少なりとも覚悟がいる。
嬉しい問題
重複して選択に困るぐらいモジュールがありすぎるというのは、一歩離れて考えてみるとそのエコシステムにとっては嬉しい問題だ。それだけ勢いがあるという証拠であり、長期的には良いものが選ばれ勝ち残っていくからだ。
