天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

フロントエンドの技術選定 ~2023を振り返る~ Lunch LTに参加してきた

findy.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

2023年5月に、Next.js 13.4がリリースされ、AppRouterがstableとなりました。その後、実際に自社のプロダクトに導入する組織も増え、改めてPages Routerに戻す方やRemixへの移行を決断する方など、メリットとデメリットも見えてきております。

本イベントでは、上記の流れにおいて自社のサービスにおいて、SSRやSSG、またはSPAが適しているのかという点について考え技術選定を行われた方々をお呼びし、明日から使える気づきや学びを得られるイベントを目指します。

会の様子

LT1「RemixでWeb標準を学んだ一年間」

最初になかざんさんから、社内向けの収益計算システムでRemixを採用した話がありました。

Remixを採用したのは、Next.jsへの逆張り的な側面はありつつも、一番はWeb標準を覚えられることができる点が魅力的に映ったということです。

実際に採用してみて、昔からあるWeb標準を改めて知ることができたり、MDNを参照する頻度が格段に増えてRemixやReactに依存しないスキルを身につけることが結果的にできたということでした。

LT2「React ViteからNext.jsへ切り替えたプロセスとApp Router化のボトルネック

続いて、sumirenさんから、React ViteからNext.jsへ乗り換えした事例紹介(ただしApp Routerにはできなかった話)がありました。

React ViteからNext.jsへ乗り換えしたのは、FCPが遅かったことに対する問題意識が背景にあったということです。(Next.jsのPages Routerが魅力的だった)
また、移行する際は、React ViteとNext.jsそれぞれを並行運用したそうで、いつでも移行を中断できる体制を整えながらじっくりQAができたということでした。

ただし、App Router化はルーティングにボトルネックがあることで断念したそうで、複雑なルーティングとブラウザバックサポートがまだまだ発展途上な点が解消されるまでは移行が難しいと判断しているそうです。

LT3「一休レストランで Next.js App Router から Remix に乗り換えた話」

次に、Next.js App RouterからRemixに乗り換えた事例の話を恩田さんがしてくれました。

恩田さんが所属している一休さんでは、React Server Componentへの魅力からNext.js App Routerに移行したそうですが、

  • History APIのstateが操作できない
  • Cache-Controlヘッダを自由に設定できない
  • 安定性や継続的なアップデートに懸念を覚えた

の3点の課題が発生し、そこから2ヶ月でRemixに乗り換えたということでした。
Remixは、上記3点の課題を解消できることに加えて、なかざんさんからも話があったようにWeb標準APIの重視が魅力的だったそうで、結果的にFastlyを有効活用できるようになり、

  • Cache Hit Ratioが5ポイント向上
  • レスポンス速度向上
  • Back Forward Cacheで既存画面との遷移体験がよくなった
  • Prefetchを積極的に利用できるようになった

といった結果を得られることができたということです。

LT4「Next.js App Router を例に考える、技術との距離感と技術選定」

最後に、izuminさんから、新プロダクトの技術選定時にどのようなことを考えていたのか?という話がありました。

izuminさんは、まず「何のためにWebフレームワークを導入するのか?」を考え、そこでルーティング機構とそれに最適化されたビルドシステムの獲得が一番の理由だと考えたそうで、これに加えて世の中に知見が多く溜まっていることや学習コストが低い点を踏まえてNext.jsとApp Routerの採用を決めたということでした。
また、上記のように重要視するポイントを決めたことで、パフォーマンスは一時的に優先順位を下げてもいいなという意思決定ができたということです。

こうして技術選定をする際には、(決定的な差がない場合は)撤退可能なパスを残して一定距離を取ることを厭わないことも大事ですが、その一方でBet Technologyするために余白を作っておくことも重要だというお話でした。

なお、プロダクトリリース時には結果的にApp Routerから撤退することになったそうで*1、やはり一定距離を取りながらApp Routerを採用していてよかったと思ったそうです。

会全体を通した感想

App Routerの採用がここ最近増えてきているなあというのは感じていたも一方でなかなか実現が難しい機能もあると思っていたので、撤退する企業さんの事例がこれだけ聞けたのは、納得感がありました。

また、フレームワークに依存しない技術力の獲得という意味でRemixはやはり魅力的だなあと感じました。

*1:作りたい機能がApp Routerでは実現できなかった