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

なかよくけんか

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

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

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

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

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

雑オマケ

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

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

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

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

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

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

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

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

後記

/(^o^)\

まあまあ

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

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


Author

ahomuAyumu Sato

overflow, Inc.VPoE

東京資本で生きる名古屋の鳥類

Web 技術、組織開発、趣味など雑多なブログ。技術の話題は zenn にも分散して投稿しています。

Bio: aho.mu
X: @ahomu
Zenn: ahomu
GitHub: ahomu

Related

お探しの記事は見つかりませんでした。

Latest

Archives

Tags

Search