この記事では、ウェブ アプリケーションで使用するライブラリやフレームワークを選択する方法について説明します。このドキュメントでは、解決しようとしているビジネス上の問題に適した 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 設計パターンを使用して、ライブラリとのすべてのやり取りをラップし、コードベースの単一ファイルに含めることができます。これにより、プロキシはコードベース内の他の部分に対して、より直感的な API を提供できます。
使いやすさには、規則が大きな役割を果たします。直感的な API を含むライブラリは、直感的でない API（理解するのに多くの実験が必要）と比較して、数時間、場合によっては数日分の作業時間を節約できます。
アップデート
たとえば、いくつかの数値計算を行う完全に機能するライブラリの場合、そのようなライブラリは更新が必要になることはほとんどありません。実際、変化の激しいウェブ開発の世界では、機能が完全なライブラリはめったにありません。しかし、ライブラリの作成者が迅速に対応し、更新を積極的に行うことが望ましい場合もあります。新しい研究や発見によって、より良い方法が見つかる可能性があるため、ライブラリやフレームワークで使用される手法は常に変更される可能性があります。
ライブラリやフレームワークを選択する際は、アップデートがどのように処理されるかに注意してください。また、そのような決定が以下に影響する可能性があることに注意してください。
- ライブラリの公開スケジュールは妥当か。たとえば、ソースコード リポジトリの更新は頻繁に行われる可能性がありますが、そのような更新が適切に「公開」または「リリース」されていない場合、そのような更新をダウンロードするのは困難です。
- ライブラリは、適切なソフトウェア バージョニング スキームでアップデートをリリースしていますか？ライブラリは時間を節約するためのものです。ライブラリのバージョンを更新するたびにコードを予期せず変更しなければならない場合、そもそもそのライブラリを使用する目的が損なわれる可能性があります。互換性を破る変更が避けられない場合もありますが、理想的には、変更はまれであり、ライブラリのユーザーに強制されるものではありません。
- ライブラリは下位互換性に配慮していますか？ソフトウェア アップデートには、互換性を破る変更が含まれることもありますが、下位互換性のレイヤも提供されます。これにより、ライブラリの利用者は、コードを最小限変更するだけで最新のライブラリ バージョンを使用できます。
ライセンス
ソフトウェア ライセンスは、サードパーティ ソフトウェア ライブラリを使用する際の重要な側面です。ライブラリの作成者は、ライブラリにライセンスを割り当てることができます。ライブラリの使用を検討している場合は、ライセンスの選択が影響する可能性があります。
たとえば、JavaScript ライブラリには、非営利環境での使用を許可するソフトウェア ライセンスが適用されている場合があります。個人的な趣味のプロジェクトには、これが最適な選択肢となる可能性があります。プロジェクトに商用要素がある場合は、エンタープライズ ライセンスを検討する必要があります。
不明な点がある場合は、専門の法律顧問に相談するか、社内の法務チームに判断を委ねることを検討してください。
コミュニティ
ユーザーやコントリビューターの大規模なコミュニティがあるライブラリやフレームワークは有益な場合がありますが、これは保証されていません。一般に、ライブラリやフレームワークのユーザー数が多いほど、メリットを享受できる可能性が高くなります。開発コミュニティに参加するメリットとデメリットは次のとおりです。
長所:
- ユーザーベースが大きいということは、バグが早期に頻繁に発見される可能性が高いことを意味します。
- 活発な大規模コミュニティがあれば、対象のライブラリやフレームワークに関するチュートリアル、ガイド、動画、さらにはコースも増える可能性があります。
- 活発なコミュニティが大規模であれば、フォーラムや質問と回答サイトでのサポートが充実し、サポートに関する質問に回答が得られる可能性が高くなります。
- コミュニティが活発であれば、ライブラリやフレームワークへの外部コントリビューターが増える可能性があります。作成者のロードマップにない機能を提供できます。
- コミュニティ内でライブラリやフレームワークの人気が高い場合、同僚や仲間がそのライブラリやフレームワークについて聞いたことがある、またはよく知っている可能性が高くなります。
短所:
- ユーザーベースが大きく多様なプロジェクトは、機能が絶えず追加されることで肥大化する可能性があります。肥大化したライブラリはウェブ パフォーマンスに悪影響を及ぼす可能性があります。
- コミュニティが活発で熱心なプロジェクトは、作成者やメンテナーにとってストレスになることがあり、コミュニティのモデレーションが重荷になる可能性があります。
- プロジェクトが急速に成長しているにもかかわらず、適切なサポートが提供されていない場合、コミュニティが有害な兆候を示し始めることがあります。たとえば、初心者やジュニアのウェブ デベロッパーは、ゲートキーピングにより、特定のコミュニティで歓迎されていないと感じることがあります。
ドキュメント
JavaScript ライブラリやフレームワークがどれほどシンプルでも複雑でも、ソフトウェア ドキュメントは常に役立ちます。非常に経験豊富なデベロッパーでも、コードを自分で理解するのではなく、ドキュメントを使用します。ドキュメントには、使用すべき API とその使用方法が明記されています。
ドキュメントにはサンプルコードも含まれているため、すぐに使い始めることができます。ライブラリやフレームワークを評価する際は、次のような質問を検討してください。
- ライブラリにドキュメントは含まれていますか？そうでない場合は、自分で解決することに慣れる必要があります。
- ドキュメントは明確でわかりやすく、曖昧さがないか。多くのデベロッパーは、ドキュメントの作成に多くの時間を費やしています。小さなことのように思えるかもしれませんが、テキスト ドキュメントの明瞭さは生産性に大きな影響を与える可能性があります。
- ドキュメントは完全に自動生成されますか？このようなドキュメントは理解しにくく、API の使用方法に関する明確なガイダンスが提供されないこともあります。
- ドキュメントは最新ですか？ドキュメントのメンテナンスは、後回しにされることがあります。ライブラリが更新されてもドキュメントが更新されない場合、開発時間が無駄になる可能性があります。
- ドキュメントは包括的で、複数の形式で利用できますか？ユーザーガイド、サンプルコード、リファレンス ドキュメント、ライブデモ、チュートリアルはすべて、ライブラリやフレームワークを効果的に使用するのに役立つ貴重なドキュメント形式です。
ドキュメントが常に完全であるとは限りませんが、それで問題ありません。組織のニーズ、プロジェクトの要件、ソフトウェアの複雑さを評価し、それに基づいて必要なドキュメントのレベルを決定する必要があります。
まとめ
初めてライブラリやフレームワークを選ぶときは、圧倒されるのが普通です。他のことと同様に、タスクについて学び、練習すればするほど、上達します。次に使用するライブラリやフレームワークを選択する際に、この記事を参考にするとよいでしょう。この投稿の見出しをチェックリストとして使用できます。たとえば、このライブラリはパフォーマンスが高いか、このライブラリは、ウェブのユーザー補助に関するビジネス基準を満たしていますか？
ライブラリとフレームワークには、他にも考慮すべき点があります。この投稿では詳しく説明していませんが、
- 拡張性: カスタム ロジックやカスタム動作でライブラリを拡張するのがどれほど簡単か。
- ツール: 該当する場合、ライブラリにコードエディタ プラグイン、デバッグツール、ビルドシステム プラグインなどのツールがあるか。
- アーキテクチャ: クリーンなコードは重要ですが、ライブラリの全体的なアーキテクチャは合理的ですか？
- テスト: プロジェクトにテストスイートがあるか。プロジェクトのウェブサイトでは、テストスイートが最新の commit に対して合格していることを示すバッジやインジケーターを使用していますか？
- 互換性: ライブラリは、現在使用している他のライブラリやフレームワークと適切に連携するか。
- 費用: フレームワークの費用はいくらか。オープンソースですか、それとも購入可能ですか？
- 虚栄の指標: これは、基準リストの下位に置くか、完全に無視する必要がありますが、プロジェクトの「投票」、プロジェクトを表すソーシャル メディア アカウント、プロジェクト ページに未解決のバグや問題がいくつあるかを考慮することもできます。