【2022年版】Webフロントエンド開発にお勧めの最新フレームワーク・ライブラリ・ツール15選

2022年4月7日投稿カテゴリ：プログラミング

著者: jMatsuzaki

【2022年版】Webフロントエンド開発にお勧めの最新フレームワーク・ライブラリ・ツール15選

私の愛しいアップルパイへ

現在我が子TaskChute Cloud v2.0を作り始めたこともあり、最近のWebフロントエンド開発周りの最新情報をインプットしています。

ここのところたいへん優れたツールが続々と出てきており、驚くばかりです。

今回は最新のWebフロントエンド開発関連技術として、私が特に注目しているフレームワーク・ライブラリ・ツールを丸っと紹介していきます。これを読めば、最近ホットな技術がサクッとつかめることを信じてやみません。

特に、あなたがこれから新しいサービスを作るときの選択肢として参考になれば幸甚です。

リッスン！

（静かになる）

Webフロントエンド開発にお勧めのフレームワーク・ライブラリ・ツール15選

TypeScript

天下のMicrosoft様謹製、JavaScriptのスーパーセットとなるTypeScriptはもう紹介するまでもないでしょう。

もはや業界標準と言ってもよいくらいの言語ですから、今後のプロジェクトでJavaScriptを書くことはもうない気がしています。

最初は静的型付けを面倒に感じるところがありますが、一度慣れてしまうと素のJavaScriptには戻れません。

TypeScriptの競合として天下のMeta（旧Facebook）様が作られたFlowも気になっているのですが、TypeScriptの完成度と広まり具合をみるとやはりメインで使っていくのはTypeScriptになるかなと感じます。

ただ、以降で紹介しますが天下のMeta様によるフレームワークが根幹を担っているので、今後Flowの対応やアップデート状況によっては十分有力な選択肢になる可能性も感じます。

Deno

JavaScriptのランタイム&パッケージ管理システムとしては長らくNode.jsが一強でしたが、Node.jsの作者であるライアン・ダール氏によって2018年に開発が始まったDenoには大きな可能性を感じています。

ライアン・ダール氏によるNode.jsに関する反省点を生かして作られただけあって、Node.jsについてもやもやしていたところが多数解決されています。¹

TypeScriptのネイティブサポートやセキュリティ関連設定の充実、URLによるパッケージ依存関係の解決やファイルシステムへのアクセス容易性、そしてCommonJSからの卒業など魅力的な改善点が盛り込まれています。

すでに2020年にはVersion 1.0がリリースされ、実プロジェクトでの採用例も散見されるようになってきました。公式だけでなく非公式のプラグインも順調に増えてきており、選択肢として十分検討に値するでしょう。

とはいってもDenoはまだ開発が始まったばかりですから、まだ大規模なプロジェクトへの導入は難しいというのが感想です。しかし、小規模なサービスやツールであれば十分に使えるものになっています。

React

この10年でフロントエンド革命児の最有力候補といえば、天下のMeta（旧Facebook）様が地上にもたらした奇跡Reactでしょう。React前後で歴史は完全に変わってしまいました。

PropsとStateを核としてコンポーネントの状態管理を軸にフロントエンドを構築するその設計思想は、当時JavaScriptでWebサービスを作る者なら誰もが苦しんでいた部分を華麗に解決してくれました。

リリースから8年が経った現在も精力的にアップデートが重ねられており、先月2022年3月末にはv18が正式リリースされました。このバージョンでもConcurrent ReactやSuspenseなど魅力的かつ革新的な新機能が追加されています。Cooooool！²

Next.js

本番環境向けのReactを謳ったフレームワークNext.jsはReactを使った開発を大きく変えてくれました。その構成の容易さ、シンプルさ、自由度、そして技術的な改善点が生かされています。

Reactとの融合具合も絶妙で、基本的にはNext.jsの御作法を踏襲しつつ、どうしても素のReactを使わなければならない時でも対応できます。

更新の早い本家Reactへの対応もはやく、Meta様の更新をほとんどタイムラグ使えるのも良いです。

MUI5

InputやButtonなどどんなサービスでも使う共通コンポーネントを毎回ゼロからデザインして機能実装するのは面倒ですよね。私がこの世で最も嫌いな作業のうちの1つです。

そんな貪欲な私たちにピッタリのライブラリがMUIです。マテリアルUIなデザインでReactフレンドリーなコンポーネントを多数提供してくれます。

もともとMaterial-UIという名前であったのですが、2021年にv5.0へ大規模バージョンアップしたタイミングでMUIへ改名されました。v5ではReactとの連携がよりスマートになり、使いやすさが向上し、新しいコンポーネントも増えています。

上述した各InputやButtonなどはもちろんのこと、レイティングやスライダー、ダイアログなど実装が面倒なコンポーネントもカバーされていてナイスです。

デザインも秀逸ですし、Propsを渡せば細かく挙動を制御できるので自由度も高いです。パーツは基本MUIを採用して、そこから拡張していくのが良いです。

Storybook

とはいえ、MUI5だけでサービスに必要なすべてのコンポーネントを網羅するのは不可能です。基本的なHTML要素でも細かいカスタマイズがありますし、複数の基本コンポーネントを組み合わせてサービス独自のUIを作り込んでいくことが必要です。

そういったサービス独自のUIコンポーネント作り込みを強力にサポートしてくれ、運用と拡張性を大幅に高めてくれるのがStorybookです。

コンポーネントとページを分離して、コンポーネントごとにStoryと呼ばれるユースケースを定義することで、UIコンポーネントの開発プロセスを大きく改善してくれます。

Figmaと連携するプラグインもあるので、デザイナーとプログラマーが意思疎通するためのプラットフォームとしても使えます。³

また、作成したストーリーをJestと連携してUIテストの実装にも生かせます。⁴

通常のテストに加えて、普通ならいろいろとややこしくなりがちなUIのSnapshotテストや、Reactのレンダラーと連携したテストも実装できます。このあたりのアドオンが充実してるのもStorybookの良いところです。⁵⁶

特にAtomic Designと相性が良いのも気に入っていて、Atomic Designにもとづいた拡張性と保守性の高いUIコンポーネントを気持ちよく作れます。ちなみにAtomic Designの提唱者であるBrad FrostもStorybookをお勧めしています。⁷

React Relay + GraphQL

「UIの実装周りが華麗に実装できるのは分かったけれど、APIの扱いやサーバサイドはどうなの？」と賢いあなたならそろそろお考えではないでしょうか。さすがです。

フロントでAPIからフェッチしたデータをどう扱うかについて長らく最適解が見つからず悶々としていたのではないでしょうか。「本当にReduxを使ったFluxパターンを採用するしかないのか？」と何度も頭を悩ませたことでしょう。私もです。

ReduxをはじめとしたFluxパターンはとにかく実装が重たいです。それだけでなく、DBのデータをAPIでフェッチしてから、Propsを介してStateとしてReactで扱われるまでデータの生合成を保つのが一苦労です。2019年、React v16で正式に実装されたReact Hooksによって一筋の光が見えたものの、根本的にFluxパターンから抜け出せるわけではなく、満足できる解決策には至リませんでした。⁸

そんな悩める子羊たちを救ってくれたのはやはりこのお方、Meta様しかいらっしゃいませんよね。Facebookの抜本的なリニューアルに併せて、React RelayおよびGraphQLという画期的な方法を打ち出してくださいました。

GraphQLはAPI層の設計としてRESTful APIに置き換わるものです。RESTful APIは複雑なデータ構造を扱う場合特に厄介です。エンドポイントが無限に増え続け、似たようなAPIが乱立するようになり、1画面でいくつものデータフェッチを行わなければならない事態になりがちです。

GraphQLはシンプルな宣言型のクエリ言語を使って、1つのエントリポイントに対して1つのクエリだけで、複雑なデータを一括でフェッチできてしまう夢のような代物です。GraphQLはその名のとおりグラフクエリ言語（GQL）を参考にしたものですが、実態はデータベースとは完全に切り離されたAPI用の薄い層に過ぎません。

GraphQLはあくまでリクエストをビジネスロジックとデータベースへ仲介する薄いAPIレイヤにすぎません。このあたりの設計思想はMeta様のEngineering DirectorであるDan Schafer氏による解説が分かりやすいです。⁹

そのためAPI層はGraphQLを採用し、バックエンドのデータベースはMySQLやPostgreSQLなど自由に今までのRDBMSを採用できます。Cooooool！

「ハッハー！APIの設計がいくら改善されたからといって、Fluxパターンからの脱却とは無縁ではないか！」と指摘するあなたは鋭いです。

そこで、GraphQLとともに開発されたMeta様のReact Relayが登場します。React Relayはrender-as-you-fetchを実現するGraphQLクライアントです。つまり、フェッチしたとおりに画面をレンダーすることを目指したGraphQLクライアントです。これを待ってました！

React Relayを使えば、APIからフェッチしたデータをPropsやContextを介してせっせと各コンポーネントにバケツリレーする泥臭い仕事がいらなくなります。このあたりの概念はGabriel Nordeborn氏とSean Grove氏の解説が分かりやすいです。¹⁰

Fluxパターンのようにフェッチしたデータをアクションやレデューサーを巧みに操って個々のコンポーネントに配置していく涙ぐましい努力はもういりません。

コンポーネント内でそのコンポーネントに必要なデータだけを宣言して、フェッチしたデータは直接そのコンポーネントにマッピングされます。APIからフェッチしたデータが、まるでPropsで運ばれてきたように機能します。まさに”render-as-you-fetch”です。

唯一の欠点と言えるのは概念を理解するのが難解で、初期セットアップがやや難しいことです。そのうえドキュメントがまだ整備されきっておらず、日本語ドキュメントについてはわずかしかありません。ですから、で自分で動作確認しながら調べる根気が必要です。私のようにStar WarsのExampleを延々と眺めることになる可能性が高いです。

とはいえReact Relayの設計思想は本当にすばらしいので、是非あなたにも一度触ってみてほしいところです。

ちなみに、React Relayを導入するほどではない小規模なサービスの場合には、現状React Queryが有望かなと感じています。

Express + Apollo

React RelayとGraphQLのすばらしさをご理解いただけたところで、そろそろサーバサイドの実装も気になり始めたころでしょうか。

サーバサイドには当然GraphQLのリクエストを受付て、GraphQLの仕様に則したレスポンスを返せるサーバが必要です。

個人的にサーバサイドの実装はやはりフロントと同じ言語としてTypeScriptを採用するのがお勧めです。

やはりフロント側と同じ言語で、同じ環境やツールの多くを共有できるのは大きいです。チームで開発するならこのメリットは計りしれません。サーバサイドもTypeScriptで実装するようにしてから、開発がとてもスッキリしました。

そして、TypeScriptを使えるアプリケーションサーバといえば、やはりExpressでしょう。

そして、GraphQLをさばくにはExpressと連携できるApolloがイチオシです。Apolloを使えばGraphQLのリクエストを処理するために必要なものが一とおりそろいます。

ApolloにはGraphQLのリクエストをテスト送信するクライアントとしてApollo Studioなども付属してきて手厚いです。

もちろん我らがPostmanもGraphQLに対応しています。

Nexus + Prisma

ApolloがあればGraphQLを処理できますが、クライアントにReact Relayを採用するので単にGraphQLを使えるだけでなく、React Relayが求める仕様に準拠したサーバサイドを実装する必要があります。¹¹

GraphQLのスキーマ定義言語（SDL）を使ってもよいのですが、個人的にはCSSのように非効率で好きじゃありません。

GraphQLにはSDLを用いるスキーマファーストの他にJavaScriptやTypeScriptなどのプログラムを介してスキーマを構築するコードファーストのアプローチも採用できます。私はこちらをお勧めします。

ではGraphQLをコードファーストで実装するために何を使うかというと、GraphQL公式のGraphQL.jsがあるわけですが、TypeScriptが使えないので選択肢から外れます。

GraphQLのスキーマ定義をTypeScriptでスマートに実装できるフレームワークは何かというと、現状TypeGraphQLかNexusの二択になるでしょう。

私は3つの理由でNexusが好みです。第一に、記法がGraphQL.jsに近くて直感的に分かりやすいこと。第二に、Relay連携プラグインがあることで、Relayのサーバ仕様に準拠したサーバサイドを効率的に実装できること。¹²

そして第三に、Nexus開発の母体でもあるPrismaの存在です。

Prismaはデータベースへの接続とクエリを管理するTypeScript用のORM（Object-relational mapping）です。Seaquelizeは独自のスキーマファイルと言語を使ったユニークなORMです。

データベースのMigration toolも付属しているので、データベーススキーマとその更新も管理できます。

TypeScript用ORMとしてはSequelizeがよく知られていますが、よりタイプセーフに扱える特徴があります。そして、開発母体がNexusと同じですから、Nexusと連携してGraphQLフレンドリーなORMとして際立っています。

その証拠に、Prismaは標準でカーソルベースのページネーションに対応しています。また、Nexsus連携プラグインを使えば、Prismaで定義したデータベーススキーマをGraphQLのSDLに直接注入できます。Cooooool！

なお、既存のRESTful APIを使わないといけないなどの理由でNexus & Prismaの構成をいきなり導入できない場合もあるでしょう。その場合、RESTful APIやGraphQLをはじめ、幅広く柔軟にサーバサイドを実装できるNestJsが有力候補となるでしょう。

Docker

もう説明するまでもないでしょうが、サーバサイド開発の話になったのでついでに取り上げておきましょう。コンテナ仮想化を使ってサーバサイドを開発できるDockerです。

多くは語りません。これなしにサーバサイド開発はもう考えられませんよね。

Prettier

ここからはプログラミング環境におけるコーディングルールやコードの整形なども取り上げることとしましょう。まずはコードの自動整形ツールであるPrettierです。

タブ数や括弧後のスペース有無、ダブルクオートないしシングルクオートの統一など、設定したとおりにコードを自動整形してくれます。

字下げが2文字か4文字でバラバラであったり、タブとスペースが混在していたり、たまにダブルクオートが使われていたりすると発狂ものですよね。Prettierがあれば心の平穏を取り戻せます。

Prettierはプログラミングにはもう手放せないツールです。ちなみにMarkdownにも対応しているので、このブログ記事にもPrettierを適用しています。

ESLint

ESLintはコーディング規約のチェックツールです。Prettierよりも広い範囲で様々なコーディング規約を設定し、チェック、ときに自動修正してくれます。

たとえば、一度も使われていない変数宣言を注意してくれたり、returnを省略できるアロー関数の表記を指摘してくれたり、===でなく==使われている比較演算子を指摘してくれたりといった具合です。

もちろんTypeScriptやReactに特化したコーディングルールも提供されています。プロジェクトにあったルールを構成するために設定を練る必要はありますが、プログラムの質を担保するためにPrettierと併せて必要不可欠なツールです。

余談ですが、この記事で書かれた自然言語のようなMarkdownファイルはESLintできませんから、文章ファイルは代わりにtextlintを使っています。

Jest

PrettierとESlintだけではコーディング規約にもとづいているかどうかしかチェックしてくれませんから、当然プログラムのバグは発見できません。

そこで登場するのが、いわずと知れたユニットテストを行うためのツールJestです。

Jestはシンプルに書けるにもかかわらず、かなり多様なテストを実装できるのが魅力です。もちろんTypeScriptでも書けます。

テスト駆動開発（TDD）に欠かせないのはもちろんですが、いまやユニットテストなしのプログラムは書かないでしょうから、Jestは必要不可欠です。

しかも様々なフレームワークやライブラリと連携できるのも特徴で、上述した多くのフレームワークやライブラリがJestとの統合を実現しています。

かつてSeleniumを使って悪夢を見たE2Eテストですら、最近はcypressのようにシンプルなツールがありますから、良い時代になりました。

Husky + lint-staged

コードのフォーマッティングやリンティング、ユニットテストをいくら充実されたとしても、それが実際に開発プロセスの中に組み込まれていなければ道路脇の犬の糞より無意味です。

Git Hooksに組み込めばPrettierやESlint、Jestを自動実行して、エラーがあればコミットやプッシュを拒否できます。しかし、チームメンバー全員がGit Hooksを設定していなければ＜CENSORED＞です。

そこでHuskyとlint-stagedの出番です。

HuskyはGitリポジトリを介してGit Hooksを共有するための仕組みです。Pre CommitやPre PushなどのGit HooksをHuskyが管理し、共有してくれます。

lint-stagedはGitでステージングされたファイルだけを対象にコマンドを実行できるツールです。毎回すべてのソースファイルにPrettierやESLintを実行するのは面倒でしょう。Huskyとlint-stagedを組み合わせれば、コミット対象のファイルだけを対象としてPrettierやESLintを実行できます。

ちなみに私は基本Pre CommitにはPrettierとESLintを、Pre PushにはJestを設定しています。

Copilot

最後に、最近使い始めて感動したCopilotを紹介して終わりとしましょう。

CopilotはGitHubが提供するプログラムの自動生成ツールです。GitHubがOpenAIと共同開発したプログラムで、数十億行のパブリックコードによってトレーニングを受けたAIです。

使ってみると、予想以上の確率で使えるコードを自動生成してくれるので便利です。簡単だけど書くのが面倒な処理を自動生成してくれるときには特に役立ちます。

たとえば、よく書き方を忘れるSwitch文やArray.prototype.filter()、Async/awaitでpromiseを解決する処理などでしょうか。

言語は幅広く対応していますが、「Python」「JavaScript」「TypeScript」「Ruby」「Java」「Go」で特に効果的だそうです。

ちなみにOpen AIの最新モデルであるGPT-3をベースとし、Copilotをさらに進化させたプログラミングAI「CODEX」も現在プライベートβテスト中となっており、そちらも公開が待ち遠しいです。

おっともうこんな時間。今日はこのくらいにしておきましょう。

貴下の従順なる下僕　松崎より

参考文献

カテゴリ：プログラミング

TaskChute Cloud TypeScript Web フロントエンドプログラミング

著者名：jMatsuzaki

システム系の専門学校を卒業後、システム屋として6年半の会社員生活を経て独立。ブログ「jMatsuzaki」を通して、小学生のころからの夢であった音楽家へ至るまでの全プロセスを公開することで、のっぴきならない現実を乗り越えて、諦めきれない夢に向かう生き方を伝えている。