ライブラリ (library) は、再利用できる関数・クラス・モジュールの集まり です。
呼び出す側 (アプリケーション) が 必要なときに必要なものを呼ぶ という関係で、フレームワーク とは制御の方向が逆になります。
まず押さえたいポイント
- ライブラリは
呼ばれる側、フレームワークは呼ぶ側 - この向きの違いを
Inversion of Control (制御の反転 / IoC)と呼ぶ - ライブラリは複数組み合わせて自由に使える。フレームワークは原則 1 つの上に乗る
- 例えば
lodashaxiosPillowはライブラリ、LaravelRailsNext.jsはフレームワーク
ライブラリとフレームワークの違い
最もよく引用されるのが Hollywood Principle (Don\'t call us, we\'ll call you) です。
- ライブラリ — アプリ側が
ライブラリを呼ぶ(例:lodash.cloneDeep(obj)) - フレームワーク — フレームワーク側が
アプリのコードを呼ぶ(例: ルーティングが定義に従ってUserController@showを呼ぶ)
つまり、ライブラリは部品、フレームワークは骨組み、と整理できます。
どちらを選ぶか
新規プロジェクトでは、フレームワークを選んでから、必要に応じてライブラリを足していくのが定石です。
- ある程度の規模で
規約・構造・標準がほしい → フレームワーク - 単機能だけ追加したい → ライブラリ
- 複数の機能を切り貼りしたい → ライブラリの組み合わせ + 薄い独自ラッパー
<a href="/articles/pros-and-cons-of-building-your-own-framework">自作フレームワークのメリット・デメリット</a> でも整理した通り、フレームワークを自作するのは慎重に判断し、ライブラリレベルで再利用するほうが安全な場面が多いです。
SDK との違い
SDK (Software Development Kit) は、特定のプラットフォームやサービスを使うための、ライブラリ + ツール + ドキュメントのセット です。
例えば AWS SDK for JavaScript は、API を呼ぶライブラリ + 設定ツール + サンプル + 型定義をまとめたものです。
つまり、SDK には複数のライブラリが含まれることが多く、ライブラリは SDK の構成要素の 1 つ、という関係です。
よくある誤解
ライブラリ = 単機能 フレームワーク = 多機能 という覚え方は不正確です。
React は多機能でもライブラリ (制御の主体はアプリ側) ですし、Sinatra は単機能でもフレームワーク (制御の主体は Sinatra 側) です。機能の量ではなく、制御の方向で見るのが正しい区別です。
詳しくは 代表的なフレームワークとユースケース と 自作フレームワークのメリット・デメリット で、ライブラリ / フレームワーク / SDK の選び方を整理しています。