Re:Browserifyに対するDuoの優位性について

なかよくけんか

ぼくが先日の Front-end with Node.js Tools で Duo について

現状だとnpm + Browserifyと比べて優位性が低い

と書いた件について会社の同僚氏から

優位性ってとこが気にかかったんで、ちょっと書いておこうかと

と手斧が飛んできたのだけど、Reする前に事態が収拾してた。主にazu氏によって。

雑オマケ

やり場をなくした所感の吐き出しなので、雑に書かせてもらいたい。npmの安定したレジストリ（）に依存していないことも利点に入るかと思ったが、github.com だって落ちるときは落ちるしただの特徴だった。

ちょっと気になってるところ

1. require() の振る舞いが特殊（githubローダーは本質でないのでは...?）
2. packageName@version:distPath のような補足情報が必要なことが多い

1 は振る舞いが特殊な分、browserifyなどのnpmファミリーで再利用するのが面倒になってないかという懸念もある。パッケージの最終成果としては --standalone オプション使えば良いんだけど、duoのエコシステムが閉じる原因になったりしないんだろうか。

2 は一応 package.json や bower.json をうまいこと読むようになれば改善しそうではあるが、どうかなぁ...という感じ。

このような微妙な不便がgithubからモジュールを呼び出せるという利点を持っているにも関わらず、duojsのエコシステムに入った途端にスケールしづらくなるという謎の矛盾を孕んでいないだろうかという危惧を感じる今日この頃である。

npmにせよ何にせよ長いものに巻かれるのはエコシステムの基本でございます。

まあ、あんまり詳しく調べてないのでアレ。

後記

Browserifyに対するDuoの優位性について - Life goes on http://t.co/1A3xj0RIYc Re: でLayzie氏を煽る記事書こうと思ったころには出番がなくなっていた件...!

— あほむ@ (@ahomu) November 19, 2014

／(^o^)＼

完

まあまあ

npm の browserify と密に依存したフロントエンドパッケージに関する昨今の主張も全面的に信用しているわけではないし、ちょっといや、どうなんだろうという感はある。

duo の全体的なコンセプトは好きだし、segmentio が使ってることもあって悪くはないと思ってる。よってしばし静観してるところ。（日和見主義者）

---