Bowerはなぜオワコン化したのか

はじめに

最近めっきりBowerを使わなくなりました。

2015年くらいに作ってたWebアプリを久々に眺めてみると、
Bowerを使ってパッケージ管理してるのを見て懐かしさとともに時代を感じました。

「昔はBowerよく使ってたなー」
と思いつつ、なぜオワコン化(まだまだバリバリ使っている方も多いですが)したのか
自分なりに整理してみようと思いました。

TL;DR

• npm, Yarnと比較したインストール数などのトレンドを見ると明らかにBowerは落ちている
• Bower　の製作者サイドから、Bowerは非推奨でありnpm、Yarnへの乗り換えを推奨している
• Bowerが衰退した理由はいくつか挙げられる
  • npmリポジトリのフロントエンドモジュールの充実
  • npmとBowerで同じモジュールを重複管理してプロジェクトが肥大化する　など
• 今(2019年)から新規でプロジェクト作成する場合にあえてBowerを採用する旨味はあまりない

忙しい方は以下をご覧ください。
Bowerがオワコン化した理由

Bowerとは

Webアプリケーションのフロントエンドのパッケージ管理ツールです。
2013年〜2016年あたりに流行っていた印象です。

npm install -g bower

でインストールすることで利用可能になります。

bower install <package>

のようにコマンド一つで、jquery, react, Angularなどなどフロントエンドで使うパッケージのインストールや管理ができます。

Bowerとnpm

かつて、フロントエンドのパッケージとバックエンドのパッケージを

• 一緒に管理するのはちょっと...
• npmはNode.jsのパッケージを管理するためのものだから、フロントエンドのパッケージ管理には不向き

と言った流れもあり

• フロントエンドのパッケージ：　Bower
• バックエンドのパッケージ： npm

で管理することが良くありました。

ディレクトリツリーでいうと以下のような感じです。

app/
　├ bower_components/
　├ node_modules/
　├ index.html
　├　　index.js
　├　　bower.json   //フロントエンドのパッケージ依存関係を管理
　└　　package.json　　//バックエンドのパッケージ依存関係を管理

【javascript】npmとbower【ライブラリ管理】

Bowerのいま

Google Trend

Google Trendを見ると、npmやYarnと比較して勢いが低下していることがわかります。 [Google Trend npm vs bower vs yarn](https://trends.google.co.jp/trends/explore?date=today%205-y&geo=JP&q=%2Fm%2F0gx25dn,bower,Yarn)

npm trends

npm trendsで、npmやYarnと比較してみましたが 最近、Yarnにもインストール数で抜かれてしまいました。

npm trends npm vs bower vs yarn

Bower公式ページでも >we recommend using [Yarn](https://yarnpkg.com/) and [Webpack](https://webpack.js.org/) or [Parcel](https://parceljs.org/) for front-end projects

とYarnなどを使うことを推奨しています。
ご丁寧にマイグレートする方法までブログで紹介されています。
How to migrate away from Bower?

Bowerがオワコン化した理由

さぁ本題です。
私は、Bowerがオワコン化した理由は以下の5つだと考えます。

1. バンドルツールの充実

過去にはnpmはNode.jsのパッケージ管理を主としており、
フロントエンドのパッケージ管理は弱いのではと言われていましたが

• Browserify
• webpack

などのバンドルツールの充実により、npmパッケージの多くはフロントエンドでも実行可能になりました。

Bower全盛期の時代から

「package.jsonとbower.jsonの二重管理は面倒」

という声もありましたが、npmだけで賄えるようになってきたので徐々に人口が減っていったのではと思います。

2. npmとBowerで同じモジュールを重複管理してプロジェクトが肥大化する

これは特にサーバサイドをNode.jsで書いている場合ですが、
クライアントサイドとサーバサイドで同じモジュールを使う(e.g. 日付を扱うモジュール module Aとする)とき、npmとbowerはそれぞれmodule Aをnode_modules、bower_componentsにインストールするので同じモジュールなのに再利用せずにプロジェクトが肥大化してしまいます。

3. Bowerはパッケージのバージョン固定ができない

Bowerには、npmやYarnに搭載されているインストールパッケージのバージョンを
ロックする機能がありません。
パッケージのバージョンが固定されないので、

bower install

を行っても、バージョンが合わず動かなというケースもありえます。

4. Yarnの登場

パッケージのインストールは、そこそこ時間のかかるものも多く
高速にパッケージをインストール可能なYarnの登場は、Bowerのオワコン化に影響を及ぼしているのではないかと思います。

高速にパッケージインストール可能なYarnの登場により、
「早くインストールできるのでフロントエンドもYarnで」
となっていっても不思議ではありません。
(事実、私はそれでBowerを使わなくなりました)

5. Bowerのリポジトリが更新されてない

モジュールによっては、npmのリポジトリはメンテナンスされているいますが
Bowerの方はメンテナンスされてなくて古くなってることがあります。
Bowerはオワコン化してきたからメンテナンスされなくなった面もありますが
メンテナンスされなくなったせいで

「npmのリポジトリにはあるが、Bowerリポジトリにはない」

パッケージも出てきました。これはかなり辛いです。
今から新たにプロジェクトを作成する場合にあえてBowerを選択する必要もないかなと思います。

おわりに

Bowerのオワコン化には時代の流れを感じました。
よくお世話になったBowerのオワコン化は個人的に少し寂しかったり。
今当たり前に使っている、Yarnなどもいずれオワコンになってしまうのか。
やはりフロントの流れの速さはすごいなと再認識しました。

参考

npm とフロントエンドのパッケージ管理の未来

---

最後までお読み頂きありがとうございました!
Twitterでも技術ネタやデザインについてなどもツイートしているので、よかったらフォローしてもらえると嬉しいです
→　Twitter@jonghyo_