この記事では、ウェブブラウザで実行されるコードであるクライアントサイド JavaScript 環境のコンテキストで、フレームワークとライブラリの違いについて説明します。ただし、ライブラリやフレームワークはネイティブ モバイルアプリ開発など、多くのソフトウェア エンジニアリング分野の一部であるため、この記事で取り上げたポイントの一部は他の環境にも当てはまります。
この投稿では、ライブラリとフレームワークとの量的な違いではなく、質的な差異に焦点を当てています。例:
- 定量的: フレームワークは通常、制御の反転の原則に準拠しています。
- 定性的: フレームワークの経験は、就職活動の際に将来の雇用主にアピールできます。
ライブラリとフレームワークについて学ぶ理由
JavaScript ライブラリとフレームワークはウェブ全体で多用されています。他のどのウェブサイトも、JavaScript リソースの一部としてサードパーティのコードを使用しているようです。ウェブページの重量が時間とともに増加し、ユーザーに影響しています。JavaScript はページ全体の重量に大きく影響します。サードパーティのライブラリやフレームワークは、この JavaScript で構成されていることがよくあります。
「JavaScript フレームワークの使用を停止してください」と言うだけでは不十分です。フレームワークは開発者に大きなメリットをもたらします。フレームワークを使用すると、コードを効率的に記述し、機能を迅速に提供できます。代わりに、十分な情報に基づいて判断できるように、自己研鑽を積む必要があります。
「ライブラリとフレームワークのどちらを使用するべきか」という質問は、あまり一般的ではありません。ライブラリとフレームワークはまったく異なるものです。ただし、ライブラリとフレームワークは混同されることが多く、この 2 つについて理解を深めるほど、その使用について的確な判断ができるようになります。
ライブラリとフレームワークの例
サードパーティ コードは、ウィジェット、プラグイン、ポリフィル、パッケージなど、他の名称で呼ばれることもあります。ただし、これらはすべてライブラリまたはフレームワークのカテゴリに分類されます。基本的に、2 つの違いは次のとおりです。
- ライブラリの場合、アプリコードがライブラリコードを呼び出します。
- フレームワークの場合、アプリコードはフレームワークによって呼び出されます。
ライブラリ
ライブラリはフレームワークよりもシンプルで、機能の範囲が狭い傾向があります。メソッドに入力を渡して出力を受け取る場合は、おそらくライブラリを使用しています。
lodash ライブラリの例を見てみましょう。
import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello
多くのライブラリと同様に、このコードを読み、何をしているのかを理解しておくと便利です。魔法のようなものはほとんどありません。
importステートメントは、lodash ライブラリを JavaScript プログラムにインポートします。capitalize()メソッドが呼び出されます。- メソッドには単一の引数が渡されます。
- 戻り値は変数にキャプチャされます。
フレームワーク
フレームワークはライブラリよりも大きく、ページ全体の重量に大きく影響します。実際、フレームワークにはライブラリを含めることができます。
この例は、ライブラリのない単純なフレームワークを示しています。人気のある JavaScript フレームワークである Vue を使用しています。
<!-- index.html -->
<div id="main">
{{ message }}
</div>
<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';
new Vue({
el: '#main',
data: {
message: 'Hello, world'
}
});
</script>
このフレームワークの例と先ほどのライブラリの例を比較すると、次のような違いがあることがわかります。
- フレームワーク コードには複数の手法が含まれており、それらを抽象化して独自の API にしています。
- デベロッパーは、オペレーションがいつどのように行われるかを完全に制御することはできません。たとえば、Vue が
'Hello, world'文字列をページに書き込む方法とタイミングは抽象化されます。 Vueクラスのインスタンス化には、いくつかの副作用が伴います。副作用は、フレームワークを使用する場合によく見られますが、ライブラリでは純粋な関数が提供される場合があります。- フレームワークは、独自の HTML テンプレート システムを使用するのではなく、特定の HTML テンプレート システムを規定します。
- Vue フレームワークのドキュメントや他のほとんどのフレームワークのドキュメントを詳しく読むと、フレームワークで使用できるアーキテクチャ パターンがどのように規定されているかを確認できます。JavaScript フレームワークを使用すると、この作業を自分で行う必要がないため、認知的な負担を軽減できます。
ライブラリとフレームワークの使い分け
ライブラリとフレームワークの比較を読んで、どちらを使用するかを理解できるようになりました。
- フレームワークを使用すると、デベロッパーの複雑さを軽減できます。前述のように、フレームワークはロジック、動作、さらにはアーキテクチャ パターンを抽象化できます。これは、新しいプロジェクトを開始するときに特に便利です。ライブラリは複雑さの軽減に役立ちますが、通常はコードの再利用に重点を置いています。
- フレームワークの作成者は、ユーザーの生産性を高めるために、フレームワークを効果的に使用するための追加ツール、デバッグ ソフトウェア、包括的なガイドなどのリソースを開発しています。図書館の作成者も生産性を高めることを望んでいますが、図書館では専用のツールがあまりありません。
- ほとんどのフレームワークには、ウェブアプリをすばやく構築するための機能的な開始点（スケルトンやボイラープレートなど）が用意されています。ライブラリは、すでに確立されているコードベースの一部になります。
- 通常、フレームワークを使用するとコードベースが複雑になります。複雑さは最初は明らかでないこともありますが、時間が経つと明らかになることがあります。
通常、ライブラリとフレームワークを比較することはしません。これらは異なるもので、異なるタスクを実行するためです。ただし、この 2 つの方法について理解を深めるほど、どちらが最適かを判断しやすくなります。フレームワークとライブラリのどちらを使用するかは、最終的には要件によって異なります。
入れ替え可能
ライブラリやフレームワークを毎週変更することはありません。ただし、エコシステムにロックインされるパッケージのデメリットを理解しておくことをおすすめします。また、サードパーティ パッケージを使用することを決定したデベロッパーは、パッケージとアプリのソースコードの間に緩い結合を作成する責任があることを理解することもおすすめします。
ソースコードに関連付けられているパッケージは、削除して別のパッケージと交換するのが難しくなります。次のような場合は、パッケージの交換が必要になることがあります。
- メンテナンスが終了したパッケージを更新する必要があります。
- パッケージにバグが多すぎて使用できないことが判明した。
- ニーズにより適した新しいパッケージがあることがわかった場合、
- 商品の要件が変更されたため、パッケージは不要になった。
次の例を考えてみましょう。
// header.js file
import color from '@package/set-color';
color('header', 'dark');
// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');
// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');
上の例では、3 つの個別のファイルでサードパーティの @package/set-color パッケージを使用しています。このコードを変更してサードパーティ パッケージを置き換える必要がある場合は、3 か所でコードを更新する必要があります。
または、次の例に示すように、メンテナンスを簡素化し、ライブラリの使用を 1 か所に抽象化することもできます。
// lib/set-color.js file
import color from '@package/set-color';
export default function color(element, theme = 'dark') {
color(element, theme);
}
// header.js file
import color from './lib/set-color.js';
color('header');
// article.js file
import color from './lib/set-color.js';
color('.article-post');
// footer.js file
import color from './lib/set-color.js';
color('.footer-container');
上の例では、ライブラリの直接使用は抽象化されています。したがって、サードパーティ パッケージを交換する必要がある場合、更新するファイルは 1 つだけです。また、内部の set-color.js ファイルで使用するデフォルトのカラーテーマが設定されるため、コードの操作が容易になりました。
使いやすさ
フレームワークの API は複雑な場合がありますが、全体的に使いやすくするデベロッパー ツールが提供されている場合があります。使いやすさは多くの要因に基づいており、主観的な要素が非常に強い場合があります。フレームワークの使用が難しい理由:
- このフレームワークの API は、本質的に複雑です。
- フレームワークのドキュメントが不十分で、問題を解決するために多くの試行錯誤が必要になる。
- このフレームワークでは、自分やチームに馴染みのない手法が使用されています。
フレームワークでは、次のような一般的なベスト プラクティスによって、こうした課題を軽減できます。
- このフレームワークには、デバッグを容易にするデベロッパー ツールと診断ツールが用意されています。
- フレームワークには、無料のドキュメント、ガイド、チュートリアル、動画でコラボレーションする開発者の活発なコミュニティがあります。このコンテンツを使用すると、フレームワークを効率よく活用できます。
- このフレームワークは、一般的なコーディング規約に準拠した API を提供します。このような規則を以前に学習しており、コーディング スタイルに慣れているため、フレームワークを効率的に使用できます。
これらの点は通常フレームワークに起因しますが、ライブラリに起因する場合もあります。たとえば、D3.js JavaScript ライブラリは強力で、ワークショップ、ガイド、ドキュメントなどのリソースを提供する大規模なエコシステムがあり、これらはすべて使いやすさに影響します。
また、フレームワークは通常、ウェブアプリのアーキテクチャを規定しますが、ライブラリは通常、既存のアーキテクチャ（どのようなものでも）と互換性があります。
パフォーマンス
一般に、ライブラリよりもフレームワークの方がパフォーマンスに影響を与える可能性があります。ただし、例外があります。ウェブ パフォーマンスは広範な分野であり、多くのトピックが含まれます。このセクションでは、特に重要な 2 つのトピック（ツリー シェイキングとソフトウェア アップデート）について説明します。
ツリー シェイキング
バンドルはウェブ パフォーマンスのほんの一部にすぎませんが、特に大規模なライブラリではパフォーマンスに大きな影響を与えます。インポートとエクスポート中にツリー シェイキングを使用すると、アプリに不要なコードが検出されて削除されるため、パフォーマンスが向上します。
JavaScript コードをバンドルする際には、ツリー シェイキングと呼ばれる便利な手順があります。これは、コードに対して行うことができる貴重なパフォーマンス 最適化です。ただし、フレームワークよりもライブラリで行う方が簡単です。
サードパーティ コードをソースコードにインポートする場合は、通常、コードを 1 つまたは少数の出力ファイルにバンドルします。たとえば、header.js、footer.js、sidebar.js ファイルはすべて output.js ファイルに結合されます。このファイルは、ウェブアプリに読み込む出力ファイルです。
ツリー シェイキングをより深く理解するには、次のコード例をご覧ください。
// library.js file
export function add(a, b) {
return a + b;
}
export function subtract(a, b) {
return a - b;
}
// main.js file
import {add} from './library.js';
console.log(add(7, 10));
デモを目的として、library.js コードサンプルは、ライブラリが数千行に及ぶこともある実際のコードと比べて意図的に小さくしています。
単純なバンドル プロセスでは、次の出力でコードがエクスポートされる場合があります。
// output.js file
function add(a, b) {
return a + b;
}
function subtract(a, b) {
return a - b;
}
console.log(add(7, 10));
このアプリでは subtract() 関数は必要ありませんが、最終的なバンドルに含まれます。このような不要なコードがあると、ダウンロード サイズ、解析およびコンパイル時間、実行コストが増大します。基本的なツリー シェイキング アプローチでは、不要なコードが削除され、次の出力が生成されます。
// output.js file
function add(a, b) {
return a + b;
}
console.log(add(7, 10));
コードが短く簡潔になっていることに注目してください。この例ではパフォーマンスの向上はわずかですが、ライブラリが数千行に及ぶ実際のアプリでは、パフォーマンスへの影響ははるかに大きくなります。興味深いことに、Parcel、Webpack、Rollup などの最新のバンドルツールは、圧縮とツリー シェイキングを組み合わせて高度に最適化されたバンドルを作成するため、さらに一歩進んでいます。バンドル ツールの効果を示すために、Parcel を使用して、前述のコードサンプルを含むバンドル ファイルを作成しました。Parcel は、未使用のコードをすべて削除し、この単一のモジュールをエクスポートしました。
console.log(7+10);
Parcel はインポート ステートメント、関数定義、動作などの項目を削除し、高度に最適化されたコードを作成できるほどスマートです。
バンドルはウェブ パフォーマンスの側面の一つにすぎませんが、特に大規模なライブラリではパフォーマンスに大きく影響します。通常、ライブラリで行うツリー シェイキングは、フレームワークで行うよりも簡単です。
ソフトウェア アップデート
多くのライブラリやフレームワークでは、ソフトウェアの更新によって機能の追加やバグの修正が行われ、最終的には時間の経過とともにサイズが増大します。アップデートをダウンロードする必要は必ずしもありませんが、アップデートにバグの修正、希望する機能の強化、セキュリティの修正が含まれている場合は、アップデートすることをおすすめします。ただし、ワイヤーを介して送信するデータが多いほど、アプリのパフォーマンスは低下し、ユーザー エクスペリエンスへのパフォーマンスの影響は大きくなります。
ライブラリのサイズが増加した場合は、ツリー シェイキングを使用して増加を軽減できます。また、JavaScript ライブラリに代わる小さなライブラリを使用することもできます。詳細については、入れ替えをご覧ください。
フレームワークのサイズが大きくなると、ツリー シェイキングが難しくなるだけでなく、フレームワークを別のフレームワークに置き換えることが難しくなる可能性があります。詳細については、入れ替えをご覧ください。
雇用可能性
多くの企業が、特定のフレームワークを理解しているデベロッパーに厳しい要件を課していることは、半ば公然の秘密です。ウェブの基礎知識を無視して、特定の JavaScript フレームワークに関する知識のみを重視する可能性もあります。正しいかどうかにかかわらず、これは多くの職種の現実です。
いくつかの JavaScript ライブラリを知っていれば、求人への応募に不利になることはありませんが、それがあなたの強みになる保証はありません。いくつかの一般的な JavaScript フレームワークをよく理解している場合、現在のウェブ デベロッパーの就職市場では、この知識が有利に働く可能性があります。大企業の中には、非常に古い JavaScript フレームワークに固執しているところもあり、そのようなフレームワークに精通した候補者を切望している場合もあります。
このオープンシークレットを有利に利用できます。ただし、求人市場へのアプローチは慎重に、以下の点に留意してください。
- 1 つのフレームワークにのみ長い時間を費やしていると、他の最新のフレームワークを学ぶ機会を逃す可能性があります。
- ソフトウェア開発やウェブ開発の基礎を十分に理解していないにもかかわらず、フレームワーク デベロッパーとして雇用されたデベロッパーについて考えてみましょう。このデベロッパーは効果的なコードを書いていないため、そのようなコードベースで作業するのは気が遠くなる、あるいは圧倒されるかもしれません。場合によっては、このシナリオが燃え尽き症候群につながる可能性があります。たとえば、コードが遅いため、コードをリファクタリングしたり、コードのパフォーマンスをチューニングしたりすることが必要になる場合があります。
- ウェブ開発を学ぶ場合、まずウェブ開発、ソフトウェア開発、ソフトウェア エンジニアリングの基礎を重点的に学ぶことをおすすめします。このような強固な基盤があれば、任意の JavaScript フレームワークを迅速かつ効果的に習得できます。
まとめ
JavaScript フレームワークとライブラリの比較について、よく理解できましたか？グリーンフィールド プロジェクトやコンサルタントとして働いている場合を除き、フレームワークやライブラリを選択する機会は多くありません。ただし、そのような判断を下す際には、その問題に関する知識が多いほど、より多くの情報に基づいて判断できます。
ここまで学んだように、フレームワークの選択（場合によってはライブラリの選択）は、パフォーマンスなど、開発エクスペリエンスとエンドユーザーに大きな影響を与える可能性があります。