このページは Cloud Translation API によって翻訳されました。

JavaScript ライブラリとフレームワークの違い

Umar Hansa

この記事では、クライアントサイドの 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 つのトピック、ツリーシェイキングとソフトウェアアップデートについて取り上げます。

ツリーシェイキング

バンドルはウェブパフォーマンスの 1 つの側面にすぎませんが、特に大規模なライブラリでは、パフォーマンスに大きな影響を及ぼします。インポート時とエクスポート時にツリーシェイキングを使用すると、アプリにとって不要なコードを検出して削除できるため、パフォーマンスが向上します。

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 は未使用のコードをすべて削除し、次の 1 つのモジュールをエクスポートしました。

console.log(7+10);

Parcel は、インポートステートメント、関数の定義、動作などのアイテムを削除して、高度に最適化されたコードを作成するほどスマートです。

バンドルはウェブパフォーマンスの 1 つの側面にすぎませんが、特に大規模なライブラリでは、パフォーマンスに大きな影響を及ぼします。ツリーシェイキングは通常、フレームワークよりもライブラリで行うほうが簡単です。

ソフトウェアアップデート

多くのライブラリやフレームワークでは、ソフトウェアのアップデートによって機能の追加やバグの修正が行われ、最終的には時間の経過とともにサイズが増大します。アップデートをダウンロードすることは必ずしも必要ではありませんが、アップデートにバグの修正、必要な機能強化、セキュリティ修正が含まれている場合は、おそらくアップデートする必要があります。ただし、有線で送信するデータが多いほど、アプリのパフォーマンスが低下し、ユーザーエクスペリエンスのパフォーマンスへの影響は大きくなります。

ライブラリの規模が拡大した場合は、ツリーシェイキングを使用して増加を抑えることができます。または、JavaScript ライブラリの代わりに、サイズの小さいコードを使用することもできます。詳細については、スワップ可能性をご覧ください。

フレームワークの規模が大きくなると、ツリーシェイキングがさらに困難になるだけでなく、フレームワークを別のフレームワークに切り替えることが難しくなる可能性があります。詳細については、スワップ可能性をご覧ください。

雇用

多くの企業は、特定のフレームワークを熟知しているデベロッパーに対して厳しい要求を課していることは、ごくわずかな秘密です。ウェブの基礎の知識は無視して、特定の JavaScript フレームワークの特定の知識だけに焦点を絞る場合があります。正しいか間違っているかは、多くの仕事にとって現実です。

いくつかの JavaScript ライブラリの知識は、求人応募に悪影響を及ぼすことはありませんが、目立たせる保証はほとんどありません。いくつかの一般的な JavaScript フレームワークに精通していれば、雇用主は、この知識がウェブデベロッパーの現在の求人市場で好意的に受け止められる可能性は大いにあります。一部の大企業では、非常に古い JavaScript フレームワークに縛られており、そのようなフレームワークに慣れた候補者が切実に望まれることもあります。

このオープンシークレットを活用できます。ただし、求人市場へのアプローチは、以下の点を念頭に置いて慎重に行ってください。

キャリアの中で多くの時間を 1 つのフレームワークだけに費やしていると、他の最新のフレームワークで学ぶ機会を逃す可能性があることを覚えておいてください。
ソフトウェア開発やウェブ開発の基礎をしっかり理解していないデベロッパーだが、フレームワークデベロッパーとして雇われた場合を考えてみましょう。この開発者は効果的なコードを記述しておらず、そのようなコードベースで作業するのは大変だと感じるかもしれません。場合によっては、このシナリオが燃え尽き症候群につながる可能性があります。たとえば、低速であるため、コードのリファクタリングやパフォーマンスの調整が必要になることがあります。
ウェブ開発を学ぶときは、ウェブ開発、ソフトウェア開発、ソフトウェアエンジニアリングの基礎に重点を置いて始めることをおすすめします。このような強固な基盤があれば、JavaScript フレームワークを迅速かつ効果的に習得できます。

まとめ

JavaScript のフレームワークとライブラリの違いを理解したところで、グリーンフィールドプロジェクトに取り組むか、コンサルタントとして働いていない限り、フレームワークやライブラリを頻繁に選ぶことはないでしょう。ただし、このような判断を下す場合は、対象に関する知識が多ければ多いほど、判断に役立つ情報が得られます。

ここまで見てきたように、フレームワークの選択、場合によってはライブラリの選択は、開発エクスペリエンスとエンドユーザー（パフォーマンスなど）に大きな影響を与える可能性があります。