JavaScript ライブラリまたはフレームワークを選択する

ウマル・ハンザ

この記事では、ウェブ アプリケーション内で使用するライブラリやフレームワークの選択方法について説明します。ここで説明する内容は、解決しようとしているビジネス上の問題に適した 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' など）のみをインポートします。最小限の 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 の使用方法に関する明確なガイダンスが常に提供されるわけではありません。
  • ドキュメントは最新のものですか？ドキュメントのメンテナンスは、後付けで取り組む場合があります。ライブラリが更新されてもドキュメントが更新されていない場合、開発時間が無駄になる可能性があります。
  • ドキュメントは包括的で、複数の形式で提供されていますか。ユーザーガイド、サンプルコード、リファレンス ドキュメント、ライブデモ、チュートリアルはすべて、ライブラリやフレームワークを効果的に活用できる有用なドキュメント形式です。

ドキュメントが必ずしも完成しているとは限りません。それで問題ないのです。組織のニーズ、プロジェクトの要件、ソフトウェアの複雑さを評価し、それに基づいて必要なドキュメントのレベルを判断する必要があります。

まとめ

初めてライブラリやフレームワークを選ぶときは、圧倒されてしまうことがよくあります。他のものと同様に、タスクを学び、実践すればするほど、良くなっていきます。次回、使用するライブラリやフレームワークを選択する際に、この投稿が参考になります。この投稿の見出しをチェックリストとして使用できます。たとえば、「このライブラリはパフォーマンスが高いか」などです。このライブラリはウェブ アクセシビリティに関する私のビジネス基準を満たしていますか？

ライブラリやフレームワークには他にも考慮すべき点がありますが、この投稿では取り上げていません。

  • 拡張性: カスタムのロジックや動作でライブラリを拡張することはどの程度簡単か。
  • ツール: 該当する場合、ライブラリにコードエディタ プラグイン、デバッグツール、ビルドシステム プラグインなどのツールはありますか？
  • アーキテクチャ: クリーンなコードは重要ですが、ライブラリの全体的なアーキテクチャは妥当ですか？
  • テスト: プロジェクトにテストスイートがあるかどうか。プロジェクトのウェブサイトで、テストスイートが最新のコミットに合格したバッジやインジケーターを使用しているか。
  • 互換性: 現在使用している他のライブラリやフレームワークとライブラリがうまく連携しているか。
  • 費用: フレームワークの費用。オープンソースですか、それとも購入可能ですか？
  • バニティ指標: 基準リストの下位にあるか、完全に無視する必要があります。ただし、プロジェクトの「投票数」、プロジェクトを代表するソーシャル メディア アカウント、プロジェクト ページにある未解決のバグや問題の数を考慮することをおすすめします。