この記事では、ウェブ アプリケーション内で使用するライブラリまたはフレームワークを選択する方法について説明します。ここで説明する内容は、解決しようとしているビジネス上の問題に適した JavaScript ライブラリまたはフレームワークを見つける際の長所と短所を比較検討する際に役立ちます。さまざまな状況で適用される長所と短所を理解することは、利用可能な多数の JavaScript ライブラリの選択を検討するうえで重要です。
JavaScript ライブラリとフレームワークとは
JavaScript ライブラリとは最も単純な形の JavaScript ライブラリは、プロジェクトのコード内で呼び出して特定のタスクを実行できる、事前に記述されたコードです。
この記事では主に「ライブラリ」について説明します。ただし、多くの内容はフレームワークにも適用されます。基本的に、2 つの違いは次のとおりです。
- ライブラリの場合、アプリケーション コードがライブラリ コードを呼び出します。
- フレームワークの場合、アプリケーション コードはフレームワークによって呼び出されます。
次の例は、その違いを示しています。
JavaScript ライブラリを呼び出す例
JavaScript ライブラリは、特定のタスクを実行してから、制御をアプリに返します。ライブラリを使用する場合は、アプリのフローを制御し、ライブラリを呼び出すタイミングを選択します。
次の例では、アプリケーション コードが lodash ライブラリからメソッドをインポートしています。関数が完了すると、制御はアプリに戻ります。
import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello
lodash.capitalize
メソッドが実行されると、文字列の最初の文字を大文字に変換する事前作成された JavaScript コードが呼び出されます。
JavaScript フレームワークの使用例
JavaScript フレームワークは、アプリケーションの動作を構築する際に使用する事前定義されたコード テンプレートです。つまり、フレームワークを使用すると、フレームワークがアプリケーション フローを制御します。フレームワークを使用するには、カスタム アプリケーション コードを記述し、フレームワークがアプリケーション コードを呼び出します。
次の例は、Preact JavaScript フレームワークを使用するコード スニペットを示しています。
import { createElement } from 'preact';
export default function App() {
return (
<p class="big">Hello World!</p>
)
}
この例では、フレームワークが作成するコードをより細かく制御していることがわかります。場合によっては、コードの実行タイミングもフレームワークが制御します。
ライブラリを使用する理由
JavaScript ライブラリを使用すると、不要なコードの重複を回避できます。ライブラリを使用すると、日付の操作や財務計算などの複雑なロジックを抽象化できます。ライブラリを使用すると、すべてのコードをゼロから記述する手間を省いて、最初のプロダクトをリリースすることもできます。
一部のクライアントサイド JavaScript ライブラリは、ウェブ プラットフォームの癖を抽象化できます。図書館は学習ツールとしても使用できます。たとえば、アニメーションの減衰関数に慣れていない場合は、ライブラリのソースコードで減衰の仕組みを学ぶことができます。
ライブラリによっては、ライブラリの最新化と安全性維持に時間と費用を投資している大企業がバックアップしています。多くのライブラリには、ライブラリの使用方法をすばやく把握できる詳細なドキュメントが付属しています。
最終的には、JavaScript ライブラリを使用すると時間を節約できます。
ライブラリの使用状況を重視すべき理由
技術的には、ウェブ アプリケーションをゼロから開発することもできますが、無料(オープンソース)のソフトウェアを使用したり、長期的には時間と費用を節約できるソリューションを購入したりすれば、わざわざ苦労する必要はありません。利用可能な JavaScript ライブラリとフレームワークは多数あり、それぞれが問題の解決に独自のアプローチを提供し、それぞれが異なる特性を持っています。次に例を示します。
- ライブラリは、サードパーティではなく社内で作成、メンテナンスできます。
- ライブラリには、ウェブ アプリケーションに適している、または適していない特定の法的ライセンスがある場合があります。
- ライブラリが古くなっていたり、メンテナンスされていなかったりする可能性があります。
- ライブラリを使用すると、複雑なタスクを簡素化し、時間と費用を大幅に節約できます。
- ライブラリはコミュニティで広く使用され、デベロッパーの間でよく知られている場合があります。
ご想像のとおり、特性によってウェブ アプリケーションへの影響は異なります。場合によっては、それほど深く考えなくても、気に入らないライブラリを安全に交換できます。ただし、ライブラリが作業やウェブ アプリケーションに大きな影響を与える可能性がある場合は、より十分な情報に基づいたアプローチが必要になることがあります。
サーバー(クラウド環境で実行)や Raspberry Pi など、クライアントサイド以外の JavaScript 環境では、ライブラリとフレームワークの審査に使用する基準を調整する必要がある場合があります。
パフォーマンス
JavaScript ライブラリがクライアントサイド ウェブ アプリケーションのパフォーマンスに及ぼす影響は、無視できません。JavaScript ライブラリのサイズが大きい場合、ページの読み込みパフォーマンスが低下する可能性があります。ミリ秒は数百万に相当します。
アニメーションに JavaScript ライブラリを使用するシナリオについて考えてみましょう。ライブラリによっては、数十キロバイト、場合によっては数百キロバイトまで簡単に増加することがあります。このような JavaScript リソースは、ブラウザがコードをダウンロード、解析、コンパイル、実行する必要があるため、ページの読み込みに大幅な遅延が生じる可能性があります。
JavaScript ライブラリのサイズが大きいほど、ユーザーのパフォーマンスに与える影響は大きくなります。
JavaScript ライブラリまたはフレームワークを評価または使用する際は、パフォーマンスを向上させるために次のヒントを検討してください。
- サイズの大きい JavaScript ライブラリを使用する場合は、サイズの小さい代替ライブラリの使用を検討してください。たとえば、date-fns は、他のオプションよりも合理的なサイズで多くの機能を提供します。
- 前の date-fns の例に沿って、必要な関数(
import { format } from 'date-fns'
など)のみをインポートします。このアプローチは、Tree Shaking と組み合わせて使用し、最小限の JavaScript ペイロードをビルドしてユーザーに送信するようにしてください。 - Lighthouse などのパフォーマンス テストツールを使用して、特定の JavaScript ライブラリを使用した場合のパフォーマンスへの影響を観察します。ライブラリによってページの読み込み時間が 1 秒遅くなる場合は(テスト中はネットワークと CPU をスロットリングしてください)、選択したライブラリを再評価する必要があります。ページの読み込みを確認するだけでなく、問題のライブラリからコードを呼び出すウェブページの動作をプロファイリングしてください。ページの読み込みのパフォーマンスだけでは、問題の全体像を把握できません。
- ライブラリ作成者がコメントを歓迎している場合は、パフォーマンスに関する観察結果、提案、プロジェクトへの貢献を送信します。オープンソース コミュニティが活躍する場です。掛金を拠出する場合は、まず雇用主に確認する必要があります。
- bundlesize などの自動バンドル トラッキング ツールを使用して、ライブラリの予期しない大規模な更新を監視します。JavaScript ライブラリは時間の経過とともに成長することが一般的です。機能の追加、バグの修正、エッジケースなどにより、ライブラリのファイルサイズが増加する可能性があります。ライブラリの使用に同意すると、ライブラリの更新は問題が少なく、質問もほとんど発生しません。このような場合に自動化が役立ちます。
- ライブラリの要件を確認し、ウェブ プラットフォームで同じ機能がネイティブに提供されているかどうかを評価します。たとえば、ウェブ プラットフォームにはすでにカラー選択ツールが用意されているため、サードパーティの JavaScript ライブラリを使用して同じ機能を実装する必要がなくなります。
セキュリティ
サードパーティ製モジュールを使用すると、セキュリティ上のリスクが伴います。ウェブ アプリケーションのコードベース内の悪意のあるパッケージは、開発チームとユーザーの両方のセキュリティを侵害する可能性があります。
NPM エコシステムに公開されたライブラリについて考えてみましょう。このようなパッケージは正当なものである可能性があります。ただし、時間が経つとパッケージが侵害される可能性があります。
サードパーティ コードを使用する際や評価する際は、次のセキュリティに関するヒントを考慮してください。
- GitHub を使用している場合は、Dependabot などのコードのセキュリティ サービスを検討してください。または、snyk.io など、コードの脆弱性をスキャンする代替サービスを検討してください。
- コード監査サービス(使用しているサードパーティ コードを手動で監査できるエンジニア チーム)の利用を検討してください。
- 依存関係を特定のバージョンにロックするか、サードパーティのコードをバージョン管理内に commit するかを評価します。これにより、安全と見なされる特定のバージョンに依存関係を固定できます。皮肉なことに、ライブラリの重要なアップデートが適用されないため、セキュリティに逆効果になる可能性があります。
- プロジェクトのホームページ(GitHub ページがある場合)をスキャンします。未解決のセキュリティ問題が存在するかどうか、過去のセキュリティ問題が妥当な期間内に解決されたかどうかを調査します。
- 他のサードパーティ コードを使用するサードパーティ コードは、依存関係がないライブラリよりもリスクが高い場合があります。このリスクに注意してください。
ユーザー補助
ソフトウェア ライブラリとウェブ アクセシビリティの関係について疑問に思うかもしれません。ソフトウェア ライブラリはさまざまな環境で使用できますが、クライアントサイドの JavaScript ベースのライブラリのコンテキストでは、ウェブ アクセシビリティが非常に重要です。
クライアントサイドの JavaScript ベースのライブラリ(またはフレームワーク)は、ウェブサイトのユーザー補助機能の利便性を高めたり低下させたりすることができます。ページに画像スライダーを追加するサードパーティの JavaScript ライブラリについて考えてみましょう。画像スライダーでウェブ アクセシビリティを考慮していない場合、ウェブ デベロッパーはこのような重要な機能を見落とし、スライダーをキーボードで操作できないなど、重要な機能が欠落したプロダクトをリリースする可能性があります。
- レスポンシブ タイポグラフィ プラグインは、ページをズームインまたはズームアウトするユーザーをサポートしていますか?
- ファイル アップローダー プラグインは、支援機器からのファイルのアップロードをサポートしていますか?
- アニメーション ライブラリは、モーションを減らしたいユーザーをサポートしていますか?
- インタラクティブ マップ プラグインはキーボードのみでの使用をサポートしていますか?
- オーディオ プレーヤー ライブラリは、スクリーン リーダーで適切なエクスペリエンスを提供していますか?
このようなユーザー補助の要件を満たすには、ウェブ デベロッパーであるお客様の一定レベルの関与が必要になることは当然です。次に例を示します。
- 不足している機能については、該当するライブラリを引き続き使用しながら、コードベース内に実装できます。
- ライブラリの作成者がそのようなコントリビューションを許可している場合、雇用主のサポートを受けて、ライブラリに不足している機能をコントリビューションできます。
- ライブラリの作成者と対話できます。たとえば、以下のアクセシビリティ機能はロードマップに含まれていますか?これらの書籍は図書館に置くべきだと思いますか?
- 一般的なユースケースの場合は、よりアクセスしやすい代替ライブラリ オプションを検討できます。このようなライブラリは存在する場合もありますが、見つけにくい場合があります。
- 極端なケースでは、ライブラリを完全に破棄して、機能をゼロから実装しなければならないこともあります。これは、ライブラリやフレームワークの初回使用時にユーザー補助機能の操作性が低下し、ライブラリやフレームワークが無料で提供している機能の多くを元に戻す必要がある場合に発生する可能性があります。
規則
確立されたコーディング規則を使用するソフトウェア ライブラリは、扱いやすくなります。ライブラリで聞いたことがないコーディング規則が使用されている場合、そのようなライブラリをチームで扱うのは難しいかもしれません。
ライブラリが一般的なコーディング規則(共通のスタイルガイドなど)に準拠していない場合、すぐに修正できる方法はほとんどありません。ただし、次のような方法があります。
- ライブラリのソースコードと、ライブラリ ユーザーに公開されている API を区別してください。内部ソースコードでは慣れない規則が使用されている可能性がありますが、API(ライブラリの操作対象部分)で慣れた規則が使用されている場合は、特に心配する必要はありません。
- ライブラリ API が一般的なコーディング規則に従っていない場合は、プロキシ パターンなどの JavaScript 設計パターンを使用して、ライブラリとのすべてのやり取りをラップし、コードベース内の 1 つのファイルに含めることができます。これにより、プロキシはコードベース内の他の部分に、より直感的な API を提供できます。
規則は使いやすさにおいて大きな役割を果たします。直感的な API を含むライブラリは、理解するために多くのテストを必要とする直感に反する API と比較して、数時間、場合によっては数日分の人件費を節約できます。
更新
たとえば、数学的な計算をいくつか実行する完全なライブラリの場合、そのようなライブラリは更新を必要とすることはほとんどありません。実際、機能が完全なライブラリは、絶えず変化するウェブ開発の世界では珍しいものです。ただし、ライブラリ作成者が迅速に対応し、更新を積極的に行うことを望む場合もあります。新しい研究や発見によって、より優れた方法が明らかになることがあり、ライブラリやフレームワークで使用される手法は常に変更される可能性があります。
ライブラリまたはフレームワークを選択する際は、更新の処理方法に注意してください。このような決定は、次のような影響を与える可能性があります。
- ライブラリには合理的なリリース スケジュールがありますか?たとえば、ソースコード リポジトリの更新は頻繁に行われますが、そのような更新が適切に「公開」または「リリース」されていない場合、そのような更新をダウンロードするのは困難です。
- ライブラリのアップデートは、適切なソフトウェア バージョニング スキームでリリースされていますか?ライブラリは時間を節約するために使用します。ライブラリのバージョンを更新するたびにコードを変更しなければならない場合、ライブラリを使用する目的が損なわれる可能性があります。破壊的変更は避けられないこともありますが、理想的には、変更は頻繁に行われず、ライブラリの利用者に強制されないものです。
- ライブラリは下位互換性に力を入れていますか?ソフトウェア アップデートには互換性を破る変更が含まれることがありますが、下位互換性のレイヤも提供されます。これにより、ライブラリの使用者は、コードに最小限の変更を加えて最新のライブラリ バージョンを使用できます。
ライセンス
ソフトウェア ライセンスは、サードパーティのソフトウェア ライブラリを使用するうえで重要な要素です。ライブラリの作成者は、ライブラリにライセンスを割り当てることができます。ライブラリの使用を検討している場合は、ライセンスの選択が影響する可能性があります。
たとえば、JavaScript ライブラリには、非営利環境での使用を許可するソフトウェア ライセンスがある場合があります。個人的な趣味のプロジェクトの場合は、この方法が適しています。プロジェクトに商業的な要素がある場合は、エンタープライズ ライセンスの購入を検討する必要があります。
不明な点がある場合は、専門の法律アドバイザーに相談するか、社内の法務チームに相談することをおすすめします。
コミュニティ
ユーザーやコントリビューターのコミュニティが大きいライブラリやフレームワークは有用ですが、必ずしもそうとは限りません。一般的に、ライブラリやフレームワークのユーザーが多いほど、メリットが得られる可能性が高くなります。開発コミュニティに参加するメリットとデメリットを検討してください。
長所:
- ユーザーベースが大きいほど、バグが早期に発見される可能性が高くなります。
- アクティブなコミュニティが大きいということは、該当するライブラリやフレームワークに関するチュートリアル、ガイド、動画、コースが豊富にあることを意味します。
- アクティブなコミュニティが大きいほど、フォーラムや Q&A ウェブサイトでのサポートが増え、サポートの質問に回答してもらえる可能性が高くなります。
- コミュニティのエンゲージメントが高ければ、ライブラリやフレームワークに外部のコントリビューターが増える可能性があります。作成者のロードマップには含まれていない機能を提供できます。
- ライブラリやフレームワークがコミュニティ内で人気があると、同僚や仲間がそのライブラリやフレームワークを聞いたことがある、またはよく知っている可能性が高くなります。
短所:
- ユーザーベースが大きく多様なプロジェクトでは、機能が絶えず追加され、肥大化してしまう可能性があります。ライブラリのサイズが大きいと、ウェブのパフォーマンスに悪影響が及びます。
- 活発でエンゲージメントの高いコミュニティを持つプロジェクトは、作成者とメンテナンス担当者にストレスを与え、コミュニティのモデレーションが厳重に必要になる場合があります。
- 急速に成長しているにもかかわらず、適切なサポートが整っていないプロジェクトでは、有害なコミュニティの兆候が見られ始めることがあります。たとえば、初心者やジュニア ウェブ デベロッパーは、ゲートキーピングにより、特定のコミュニティで歓迎されていないと感じられることがあります。
ドキュメント
JavaScript ライブラリやフレームワークがどれほどシンプルまたは複雑であっても、ソフトウェアのドキュメントは常に役立ちます。非常に経験豊富なデベロッパーであっても、コードを自分で調べるのではなく、ドキュメントを使用します。ドキュメントには、使用すべき API とその使用方法が明記されています。
ドキュメントにはサンプルコードも記載されているため、すぐに使用を開始できます。ライブラリやフレームワークを評価する際は、次のような質問をします。
- ライブラリにはドキュメントが含まれていますか?そうでない場合は、自分で解決する能力が必要です。
- ドキュメントは明確でわかりやすく、あいまいさはないか?多くのデベロッパーはドキュメント作成に多くの時間を費やしています。小さなことに思えるかもしれませんが、テキスト ドキュメントの明確さは生産性に大きな影響を与える可能性があります。
- ドキュメントは完全に自動生成されていますか?このようなドキュメントは理解しづらく、API の使用方法について明確なガイダンスが提供されているとは限りません。
- ドキュメントは最新の状態ですか?ドキュメントのメンテナンスは、後回しにされることがあります。ライブラリが更新されていてもドキュメントが更新されていないと、開発時間が無駄になる可能性があります。
- ドキュメントは包括的で、複数の形式で入手できますか?ユーザーガイド、サンプルコード、リファレンス ドキュメント、ライブデモ、チュートリアルはすべて、ライブラリやフレームワークを効果的に使用するために役立つ貴重なドキュメント形式です。
ドキュメントが常に完全である必要はありません。組織のニーズ、プロジェクトの要件、ソフトウェアの複雑さを評価し、必要なドキュメントのレベルを決定する必要があります。
まとめ
初めてライブラリやフレームワークを選択するときは、圧倒されるのも当然です。他のタスクと同様に、タスクを学び、練習すればするほど、上達します。次に使用するライブラリやフレームワークを選択する際に、この投稿を参照すると役に立つかもしれません。この投稿内の見出しをチェックリストとして使用できます。たとえば、このライブラリはパフォーマンスに優れていますか?このライブラリは、ウェブ アクセシビリティに関するビジネス基準を満たしていますか?
ライブラリとフレームワークには、この投稿では詳しく説明していない、検討すべき点が他にもあります。
- 拡張性: カスタム ロジックや動作でライブラリを拡張するのは簡単ですか?
- ツール: 該当する場合、ライブラリにはコードエディタ プラグイン、デバッグツール、ビルドシステム プラグインなどのツールがありますか?
- アーキテクチャ: クリーンなコードは重要ですが、ライブラリの全体的なアーキテクチャは合理的ですか?
- テスト: プロジェクトにテストスイートはありますか?プロジェクトのウェブサイトでは、最新のコミットに対してテストスイートが合格したことを示すバッジやインジケーターが使用されていますか?
- 互換性: ライブラリは、現在使用している他のライブラリやフレームワークとうまく連携しますか?
- 費用: フレームワークの費用はいくらですか?オープンソースですか?それとも購入できますか?
- バニティ指標: 基準リストの下位に配置するか、完全に無視してください。プロジェクトの「投票数」、プロジェクトを代表するソーシャル メディア アカウント、プロジェクト ページに未解決のバグや問題がいくつあるかなどを考慮できます。