この記事では、ウェブ アプリケーション内で使用するライブラリまたはフレームワークを選択する方法について説明します。ここで説明する内容は、解決しようとしているビジネス上の問題に適した 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 の使用方法について明確なガイダンスが提供されているとは限りません。
- ドキュメントは最新の状態ですか？ドキュメントのメンテナンスは、後回しにされることがあります。ライブラリが更新されていてもドキュメントが更新されていないと、開発時間が無駄になる可能性があります。
- ドキュメントは包括的で、複数の形式で提供されていますか。ユーザーガイド、サンプルコード、リファレンス ドキュメント、ライブデモ、チュートリアルはすべて、ライブラリやフレームワークを効果的に使用するために役立つ貴重なドキュメント形式です。
ドキュメントが常に完全である必要はありません。組織のニーズ、プロジェクトの要件、ソフトウェアの複雑さを評価し、それに基づいて必要なドキュメントのレベルを判断する必要があります。
まとめ
初めてライブラリやフレームワークを選択するときは、圧倒されるのも当然です。他のタスクと同様に、タスクを学び、練習すればするほど、上達します。今後、使用するライブラリやフレームワークを選ぶ際にこの投稿を参照することをおすすめします。この投稿内の見出しをチェックリストとして使用できます。たとえば、このライブラリはパフォーマンスに優れていますか？このライブラリはウェブ アクセシビリティのビジネス基準を満たしていますか？
ライブラリとフレームワークには、この投稿では詳しく説明していない、検討すべき点が他にもあります。
- 拡張性: カスタムのロジックや動作でライブラリを拡張することはどの程度簡単ですか。
- ツール: 該当する場合、ライブラリにはコードエディタ プラグイン、デバッグツール、ビルドシステム プラグインなどのツールがありますか？
- アーキテクチャ: クリーンなコードは重要ですが、ライブラリの全体的なアーキテクチャは合理的ですか？
- テスト: プロジェクトにテストスイートはありますか？プロジェクトのウェブサイトでは、最新のコミットに対してテストスイートが合格したことを示すバッジやインジケーターが使用されていますか？
- 互換性: ライブラリは、現在使用している他のライブラリやフレームワークとうまく連携しますか？
- 費用: フレームワークの費用はいくらか。オープンソースですか？それとも購入できますか？
- 虚栄心を満たす指標: 基準リストの下位に配置するか、完全に無視してください。プロジェクトの「投票数」、プロジェクトを代表するソーシャル メディア アカウント、プロジェクト ページに未解決のバグや問題がいくつあるかなどを考慮できます。