piapia123
ja

定番 JS ライブラリ

早見表

処理はすべてブラウザ内で完結します。データは送信されません

入力
ファイルをここにドロップすると読み込めます
出力

「これは何のライブラリを使えばいいのか」の対照表を用途別にまとめました。日付と時刻、HTTP リクエスト、ユーティリティ関数、状態管理、フォームと検証、チャートと可視化、UI とスタイル、アニメーション、グラフィックスと 3D、ドキュメントとファイル、テキストと解析、エディター、ビルドとテスト、その他の定番です。各項目にそのライブラリが何をするかと、インストール コマンドを載せています。 なぜ「人気順」ではなく用途別なのか。 人気ライブラリのランキングには権威ある出典がなく、半年で古くなります。一方で「日付処理はどれ」「グラフはどれ」という問いの答えはずっと安定しており、実際に検索されるのはそちらです。だからここでは順位を付けず、用途ごとに並べています。 ⚠️ 保存するのはパッケージ名だけ。URL もバージョン番号も持ちません。 これは意図的で、ネット上の多くの「JS ライブラリ一覧」との最大の違いです。公式サイトのアドレスは変わりますし(ドメイン変更、サブドメインへの移動、改名)、バージョン番号は毎日動きます。しかし npm のパッケージ名は安定した識別子です。インストール コマンドもパッケージページも名前から算出するため、この表には間違えようのない URL しかなく、古くなりようのないバージョンしかありません。 もう一つの原則:確実に存在するパッケージだけを載せること。一つ少ないほうが、「こういう名前だったかも」という名前を載せるよりましです —— 間違った名前で `npm i` すると無関係なパッケージが入り、何もないより悪いからです。用途の欄も、形容詞ではなく具体的な能力を書くことを求めています。

機能

  • 定番 40 以上を十四分類で:日付、リクエスト、ユーティリティ、状態、フォームと検証、チャート、UI とスタイル、アニメーション、グラフィックスと 3D、ドキュメント、テキスト、エディター、ビルドとテスト、その他
  • パッケージ名で検索:dayjs と入力すると用途・分類・インストール コマンド・パッケージページが出ます
  • 用途で検索:「チャート」「ドラッグ」などで、その領域の選択肢を一覧
  • 分類で検索:その種類をすべて一覧
  • そのままコピーできるインストール コマンド(`npm i dayjs`)とパッケージページ
  • インストール コマンドもページも名前から算出 —— 間違った URL も古いバージョンも存在しません
  • 英語ページでもパッケージ名はそのまま(ターミナルに打ち込む文字列だからです)
  • 全パッケージ名は検索できるドロップダウンに。ヒントに分類が出ます
  • 空欄で全件を一覧。十四分類ごとに並びます
  • 貼り付け耐性。例文の括弧や全角文字がついても検索結果は変わりません

使い方

  1. パッケージ名(例:dayjs)を入力すると、用途・分類・インストール コマンドが出ます
  2. または用途(例:チャート)を入力して、その領域の選択肢を見ます
  3. 分類名(例:状態管理)で、その種類を一覧できます
  4. 空欄にすると全件を十四分類ごとに一覧します

よくある質問

なぜバージョン番号がないのですか?
バージョン番号は、この表で唯一すぐ古くなる情報だからです。 バージョンを固定した一覧は公開した日から古くなっていき、古いバージョンを入れさせるのは何も伝えないより悪い結果になります —— `npm i dayjs` は常に最新を取得し、具体的なバージョンは npm とロックファイルが決めます。公式サイトのアドレスを載せないのも同じ理由です。プロジェクトはドメインを変え、サブドメインに移り、改名しますし、それらはパッケージ名から導けません。導ける唯一の所在がパッケージページなので、それだけを示しています。
どうやって選んだのですか?載っていないライブラリがあるのはなぜ?
基準は「この問題に明白な既定の答えがあるか」で、スター数ではありません —— スターは変わり、人気は適切と同じではありません。だから各項目はその領域で最もよく選ばれるものです(チャートなら echarts、日付なら dayjs、リクエストなら axios)。載っていないことは悪いことを意味しません:特定のフレームワーク内でしか使われないもの、バックエンドが必要なもの、寿命が短くなったものは入れていません。また確実に存在するパッケージ名だけを載せ、一つ少なくても「こういう名前だったかも」というリスクは取りません。
lodash と es-toolkit はどちらを選ぶべきですか?
新規プロジェクトは es-toolkit で構いません:lodash のよく使う部分をはるかに小さいサイズで提供し、ネイティブ ESM と完全な型定義を備えています。lodash に留まる妥当な理由は二つ:すでにプロジェクトで使っていて移行コストが利得を上回る場合と、`_.get` のような深いパス取得や、es-toolkit がまだ網羅していない細かい関数が必要な場合です。いずれにせよ、パッケージ全体ではなく関数単位で読み込むことを勧めます —— lodash の全量読み込みは初回表示を目に見えて重くします。
ここに挙げたライブラリはすべて無料ですか?
そうとは限りません。選ぶ前に確認してください。 大半は MIT や Apache などの寛容なライセンスで、商用利用にも制限はありません。ただし注意が必要なものもあります:GSAP はコアが無料で一部プラグインが別条件、地図ライブラリは描画側が無料でもサービスが従量課金、チャートライブラリには商用版を提供するものがあります。ライセンスは変わるので、公開前にパッケージページで現在のライセンスを確認してください。とくに商用では —— この点はこの表が代わりに保証できるものではありません。
エディターの欄に当サイトが CodeMirror を使っていると書いてあるのはなぜですか?
その項目が選定の参考として事実を一つ挙げているためです。CodeMirror と Monaco のトレードオフは典型的です:Monaco は VS Code のエディター核で、補完とハイライトは最強ですが数 MB と大きく、モバイル対応も限られます。CodeMirror 6 ははるかに小さくモバイルでも動きますが、補完は自分でつなぐ必要があります。当サイトのツールページは「入力欄+ハイライト」で足りるので CodeMirror を選びました —— 完全な IDE 体験を作るなら Monaco が適しています。

関連ツール