TL; DR：日常の使用における最大の違いは、ネストされた依存関係ではありません...それは、モジュールとグローバルの違いです。
以前のポスターは基本的な違いのいくつかをうまくカバーしていたと思います。（npmのネストされた依存関係の使用は、大規模で複雑なアプリケーションの管理に非常に役立ちますが、それが最も重要な違いだとは思いません。）
ただし、Bowerとnpmの最も基本的な違いの1つを明確に説明した人がいないことに驚いています。上記の回答を読むと、npmのコンテキストでよく使用される「モジュール」という単語が表示されます。しかし、それは単なる構文の違いであるかのように、さりげなく言及されています。
しかし、モジュールとグローバル（またはモジュールと「スクリプト」）のこの区別は、おそらくBowerとnpmの最も重要な違いです。すべてをモジュールに配置するnpmアプローチでは、ブラウザーのJavascriptの記述方法を変更する必要があります。
バウアーアプローチ：<script>タグのようなグローバルリソース
ルートでは、Bowerは古いスクリプトファイルをロードします。これらのスクリプトファイルに何が含まれていても、Bowerはそれらをロードします。これは基本的に、Bowerがすべてのスクリプトをプレーン・オールド<script>の<head>HTMLに含めるのと同じことを意味します。
つまり、これまでと同じ基本的なアプローチですが、便利な自動化機能がいくつかあります。
- 以前は、プロジェクトのリポジトリに（開発中に）JSの依存関係を含めるか、CDN経由で取得する必要がありました。これで、リポジトリで余分なダウンロードの重みをスキップでき、誰かが
bower installローカルで必要なものをすばやく簡単に実行できます。
- Bowerの依存関係がそので独自の依存関係を指定している場合
bower.json、それらもダウンロードされます。
しかし、それを超えて、バウアーは私たちがjavascriptを書く方法を変えません。Bowerによってロードされたファイル内に含まれる内容については、何も変更する必要はありません。特に、これは、Bowerによってロードされたスクリプトで提供されるリソースが（通常、常にではないが）グローバル変数として定義され、ブラウザー実行コンテキストのどこからでも利用できることを意味します。
npmアプローチ：一般的なJSモジュール、明示的な依存関係注入
Nodeランドのすべてのコード（したがって、npmを介して読み込まれるすべてのコード）は、モジュールとして（具体的には、CommonJSモジュール形式の実装として、または現在はES6モジュールとして）構造化されています。したがって、NPMを使用してブラウザー側の依存関係を処理する場合（Browserifyまたは同じことを行う他の何かを介して）、Nodeと同じようにコードを構成します。
私が「なぜモジュールなのか」という問題に取り組んだよりも賢い人たちですが、ここにカプセルの要約があります：
- モジュール内のすべてのものは事実上名前空間になっています。つまり、もはやグローバル変数ではなく、意図せずに誤って参照することはできません。
- モジュール内の何かは、それを利用するために、特定のコンテキスト（通常は別のモジュール）に意図的に注入する必要があります
- つまり、アプリケーションのさまざまな部分で同じ外部依存関係（たとえば、ロダッシュ）の複数のバージョンを使用でき、それらが衝突/競合することはありません。（これは驚くほど頻繁に発生します。独自のコードが1つのバージョンの依存関係を使用したいが、外部依存関係の1つが競合する別のバージョンを指定しているためです。または、それぞれ異なるバージョンを必要とする2つの外部依存関係があります。）
- すべての依存関係は特定のモジュールに手動で挿入されるため、それらについて推論するのは非常に簡単です。あなたは事実を知っています：「これに取り組むときに考慮する必要がある唯一のコードは、私がここに注入するために意図的に選択したものです」。
- 注入されたモジュールのコンテンツでさえ、割り当てられた変数の背後にカプセル化され、すべてのコードが制限されたスコープ内で実行されるため、驚きと衝突はほとんど起こりません。依存関係の1つからの何かが、気付かないうちに誤ってグローバル変数を再定義する、またはそうする可能性ははるかに低くなります。（それはでき起こるができますが、通常はそれを行うためにあなたの方法のうちに行かなければならない、のようなもので
window.variable。まだ発生しやすいという1件の事故が代入されthis.variable、それを実現していないことはthis、実際にありますwindow現在のコンテキストで。）
- 個々のモジュールをテストしたいときは、非常に簡単に知ることができます。モジュール内で実行されるコードに影響を与えているもの（依存関係）は何か？そして、明示的にすべてを注入しているので、これらの依存関係を簡単に模倣できます。
私にとって、フロントエンドコードでのモジュールの使用は、結局のところ、推論とテストが容易な非常に狭いコンテキストで作業し、何が起こっているかについてより確実なものにすることです。
CommonJS / Nodeモジュールの構文の使用方法を習得するには、約30秒しかかかりません。モジュールとなる特定のJSファイル内で、まず、次のように、使用する外部依存関係を宣言します。
var React = require('react');
ファイル/モジュール内では、通常どおりに何でも行い、外部ユーザーに公開したいオブジェクトまたは関数を作成し、おそらくそれを呼び出します myModuleます。
ファイルの最後で、次のように、世界と共有したいものはすべてエクスポートします。
module.exports = myModule;
次に、ブラウザーでCommonJSベースのワークフローを使用するには、Browserifyなどのツールを使用して、これらの個々のモジュールファイルをすべて取得し、実行時にそれらのコンテンツをカプセル化し、必要に応じて相互に挿入します。
また、ES6モジュール（BabelなどでES5にトランスパイルする可能性が高い）は広く受け入れられており、ブラウザーとNode 4.0の両方で機能するため、それらの概要についても言及する必要があります。
このデッキでモジュールを操作するためのパターンの詳細。
編集（2017年2月）：Facebookの糸は、最近のnpmの非常に重要な潜在的な置き換え/補足です。npmが提供するものに基づいて構築された高速で確定的なオフラインパッケージ管理。JSプロジェクトは一見の価値があります。特に、プロジェクトを簡単に入れ替えることができるためです。
編集（2019年5月）「Bowerがついに非推奨になりました。ストーリーの終わり。」（h / t：簡潔な要約については、以下の@DanDascalescu。）
また、Yarn はまだアクティブですが、Yarnの主要な機能の一部を採用すると、Yarnの勢いの多くはnpmに戻りました。
