この記事では、ウェブブラウザで実行されるコードであるクライアントサイド 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 フレームワークとライブラリの比較について、よく理解できましたか?グリーンフィールド プロジェクトやコンサルタントとして働いている場合を除き、フレームワークやライブラリを選択する機会は多くありません。ただし、そのような判断を下す際には、その問題に関する知識が多いほど、より多くの情報に基づいて判断できます。
ここまで学んだように、フレームワークの選択(場合によってはライブラリの選択)は、パフォーマンスなど、開発エクスペリエンスとエンドユーザーに大きな影響を与える可能性があります。