はじめに
この記事は GENDA Advent Calendar 2023 13日目の記事です。
株式会社GENDA FE/BEエンジニアの shinnoki です。今年は自分にとって色々と変化のあった年で、年初にはアーリーのスタートアップでCTOを務めておりましたが、ご縁があり8月にGENDAに入社いたしました。
最近社員インタビューも公開されて入社の経緯なども触れていただいたため、興味があればぜひご覧ください。
今年は個人的にあまり最新技術のキャッチアップができていなかったことを差し引いても、フロントエンド界隈では激動の1年だったのではないでしょうか。
最新技術のキャッチアップが大変なのはフロントエンドに限ったことではなくどの領域においても発生する話ですが、フロントエンドは特に大変だよねという話は周囲からもよく聞くため、感覚として間違っていないと思います。
これらとどう付き合っていくか、個人的な考えをまとめてみました。
※ タイトルはフロントエンドとしましたが自分が React に関わる機会が多いため React に偏っています。
※ 技術的な優劣の主張ではなく個人的な知見に基づくポエムであり、所属組織を代表するものではありません。
2023年のフロントエンド開発ふりかえり
React 関連
React 関連だと、なんといっても5月にリリースされた Next.js 13.4 で React Server Components をサポートする App Router が、10月の Next.js Conf のタイイングでリリースされた Next.js 14 で Server Actions が Stable になったのが大きなニュースでした。
特に Server Actions 内から直接 SQL をコールするサンプルは SNS 上で大きな反響を呼びました。
React Server Components の概念自体は2020年には発表されていたのですが、いざ触れるものとして出てきたことで受け入れられ方は様々だったように思います。
また9月には Remix v2 がリリースされました。
Remix 自体が素晴らしいフレームワークであることは間違い有りませんが、どちらかというと上記の Next.js への幻滅から検討に上がることが多かったように思います。
リニューアルされた React 公式ドキュメント react.dev（日本語版） が正式リリースされたのも今年3月でした。
サンプルコード等が全面的にモダンな書き方に見直され、とても分かりやすいドキュメントになりました。
Start a New React Project からは Create React App は消え
- Next.js
- Remix
- Gatsby
- Expo (for native apps)
という並びになっており、 Gatsby は静的サイト、 Expo は React Native 向けなので、今から新しく React で Web アプリケーションを開発するなら Next.js か Remix を採用するのは自然な選択肢になるでしょう。
生成AIの活用
今年は開発の文脈に限らず ChatGPT を初めとした生成AIの活用が話題になりましたが、
2月に GitHub Copilot for Business が GA になったのも身の回りでは大きな影響がありました。
また、まだベータ版ですが v0.dev のようなUIコンポーネントの生成ツールは今後のデザイン・開発の在り方を大きく変えていきそうです。
で、全部についていく必要あるの？
そもそも私たちはなぜフレームワークやライブラリのアップデートに追従する必要があるのでしょうか。
主な理由としては以下が挙げられるように思います。
- 新機能を使いたいから
1-a. 今までできなかったことができるようになるから
1-b. パフォーマンスの向上が見込めるから
1-c. 開発者体験（≒開発生産性）の向上が見込めるから - バグ、セキュリティ周りの修正が必要だから
- 最新のものを使ってイケイケ感を出したいから
1. の中でも 1-a. はバックエンドやフロントエンドで起こることは実はそこまでなく、積極的なアップデートをする理由としては 1-b. もしくは 1-c. を見込んで行います。（モバイルアプリやデスクトップアプリの領域だとOSのアップデートに伴い発生します。）
何に重きを置くかはプロジェクトによって異なります。
BtoC でパフォーマンスやユーザビリティが厳しく求められるシステムであれば 1-b. のためにアップデートすることもありますが、社内システムや BtoB のシステムでは細かなパフォーマンスまで求められることは少なく、アップデートにかかる工数を上回って開発生産性向上によるアウトカムがあるのかどうかは考える必要があるでしょう。
上記の Server Actions は上手く使うと 1-b. に対して大きなメリットがあるのですが、ついでに 1-c. を解決するものかのように見せてしまったのが反発が強かった部分なのかなと思います。（長期的には Server Actions を中心としたエコシステムが形成されて開発者体験も良くなるのではと推測しています。）
2. は発生したら原則的にやらなければいけませんが、2. のためにアップデートしたいのに他の破壊的変更が含まれてしまうととても厄介なので、そうなってしまうことを防ぐために最新版に積極的に追従しない場合でも定期的にアップデートする必要があります。
3. はあえてわかりやすく砕けた表現にしましたが、あくまで 1. や 2. の副次的な効果として技術発信やメンバーのエンゲージメントにもつながるのであれば大事な観点です。（1. や 2. を度外視して 3. に走るのは本末転倒です。）
結論、何のために追従するのかはプロジェクトによって異なるためそれぞれで考える必要があり、全てのプロジェクトで最新のフレームワークやライブラリを使うのが理想という訳ではないと考えます。
いま App Router に移行する必要はあるか
ここによると今後のアップデートでも当面は Pages Router のサポートは続くようです。
Is the Pages Router going away?
No. We are committed to supporting pages/ development, including bug fixes, improvements, and security patches, for multiple major versions moving forward. We want to ensure developers have enough time to incrementally adopt the App Router as they're ready.
Using both pages/ and app/ in production together is supported and encouraged. The App Router can be adopted on a per-route basis.
一方で後半の文章からは、最終的には App Router の使用を推奨するようなニュアンスが受けてとれます。
これを踏まえると2023年12月時点では、新しいプロジェクトでは将来の移行コストを考えると App Router を採用したほうが良さそうですが、すでに Pages Router で実装されているものの移行は必ずしも急がないでもいいんじゃないかなというのが個人的な意見です。
設計思想がない状態で付け焼き刃で移行を急いでしまうと将来的に大規模なリファクタリングが必要になってしまう可能性があるので、小さく試して知見を貯めてから全体を移行するのが良さそうです。
引用文の最後の行でも推奨されているように段階的に移行するのも良いでしょう。
もし移行すると決まった際でも、まずは全てのページに "use client"; をつけて回っても全然いいと思っています。
まとめ
この1年、フロントエンドでは大きな変化が次々と訪れました。（フロントエンドあるあるではありますが、特にこの1年は大きかったと思います。）
自分が新しい技術のキャッチアップが出来ていないことへの言い訳をつらつら書いただけですが、キャッチアップが間に合わずに不安に思っている方は多く居ると思い、考え方の一助となればと思います。
皆さんそれぞれの最新技術との付き合い方をシェア頂けたらとても嬉しいです。
個人的にはこの記事をまとめたことで、キャッチアップしなきゃという義務感からくる焦りを研究対象としてのワクワクに変えることが出来たかなと思います。
イケイケ感、出していくぞ 💪
Discussion