概要

「Next.jsやらないと駄目かなあ」とうっすら脳裏にあったのですが・・

やり始めなければならない理由がポロポロと見え始めてきたので、本格的に取り入れることにしました。

弊社ではWebクライアント側のアプリではVue.js系をずっと使ってきており、Nuxt.jsというフレームワークを主に利用していました。

思い返せば、2017年の春ごろになりますが・・（もう5年も前のことですが）
その頃開発をお手伝いしていた会社さんで「Vue.jsが流行ってきていて取り入れたい」みたいな話があり、Vue.jsを使ってプロトタイプや管理画面を構築したのがきっかけで、それ以降気に入ってずっと使っていました。

当初はrouter系やvuex等を組み合わせて使っていましたが・・どこかのタイミングでNuxt.jsという便利なフレームワークがあるのを知ってから、ずっとNuxt.jsを使っていました。（create-nuxt-appでプロジェクトの雛形を作れたのも便利でした。）

ただ、以下のような理由があって、Next.jsも本格的に活用しないとなと考えるようになりました。

• いくつかのサイドプロジェクト（私はそこではフロントエンドが担当ではなかった）でNext.jsが活用されており、軽微な修正等や連携等で学習の必要性を感じていました。
• 新規にプロジェクトを始めるときには、ある程度技術調査をするのですが、そのときに参考になるプロジェクトのソースコードや使えそうなOSSを調べるときにReactベースの数が圧倒的に多いと感じていました。
• 技術系の記事で、Vue系はややマイナーに感じることがあり、良い記事を探しづらい感がありました。
• 主にモバイルアプリのクライアントライブラリ（Jetpack Compose for Android / SWiftUI for iOS）でもReact系の影響を強く感じるため、Web側もReact系を使った方が良いのかな？ということを度々考えていました。

主に以上のような理由から、Next.jsを学習して本格的に取り入れることにしました。

直近では、弊社が関わっているNuxt.jsベースのプロジェクトの管理画面をNext.jsにフルリニューアルしました。

リニューアル開発を経て、思ったよりも開発時の体験が良かったため、今後は以下のような方針でいこうと思います。

• これ以降の新規のプロジェクトは、Next.jsベースで作ろうと思います。
• 既存のものは大きく変更せずに、Nuxt.jsを使い続けようと思います。

今回の記事では、Next.jsの導入にあたって「開発時に」良かったと思った点や不便だなと思った点などを整理したいと思います。

前提事項（活用方法）

Next.jsの導入にあたって、主に弊社でどのような使い方をしているのか？（2022年8月時点）をご紹介します。

• フロントエンド
  • Webブラウザクライアント（←Next.jsを活用 / まだまだNuxt.jsも多くのアプリで活用中）
  • Androidアプリ（Jetpack compose）
  • iOSアプリ（SwiftUI）
• バックエンド
  • APIサーバー（Rust製actix-webを最近はずっと使っています。昔はPython製のDjangoやFastAPIを使っていました。）
  • 非同期バッチ（こちらもRsutでフルスクラッチ、昔はPythonのceleryを多用していました。）
• インフラ
  • GKE on GCP / EKS on AWS

以上のような構成のものがほとんどです。

Next.jsの活用方法としては、Webブラウザで動く完全なクライアントアプリとしての利用方法にとどめています。

（認証処理を含む）ユーザーデータの更新はすべてバックエンドのサーバー側で実装していて、Next.jsではサーバーからデータを取得して表示をする部分に特化しています。

このような背景で、個人的にNext.jsで良かったなと思う点と、やっぱりNuxt.jsの方がよいのでは？と思う点をご紹介します。

良かった点と悪かった点

Next.jsで良かった点

1. Typescriptが簡単に使える
   1. Nuxt.jsでは導入しようとして萎えてやめてしまったのですが・・Next.jsでは導入が楽でした。
2. ホットリロードがめちゃくちゃ早い
   1. Nuxt.jsは開発時にページの編集した際にホットリロードが走るのですが・・規模がそこそこ大きくなってくるとやや遅いなと感じることがありました。Next.jsはめちゃくちゃ早くストレスがかなり軽減された気がします。
3. （当初の目論見通り）3rdパーティのライブラリが豊富
4. （個人的な感覚になってしまって、表現しづらいのですが・・・）コンポーネントを上からコードディングできるスタイルが書きやすい。
   1. 描画に必要な変数をプロパティから構築し、それを元にHTMLを構築するというフローがわかりやすい。それに対して、Vue系だと、HTML部分（template部分）とscript部分がうまく分離されているのですが・・コーディングする際に行ったりきたりする必要がありました。（あくまでも私の感覚です）

開発時の体験として、以上の No.1 と No.4 は特に良かったです。

Next.jsだと不便に思った点

逆にNext.jsだと不便だなと思った点が以下になります。

1. globalなcontextにアクセスしずらい（特に認証まわりのコードを書く際に苦労しました。）
   1. Nuxt.jsだとpluginを自作して、そこでサーバーサイドでもクライアントサイドでも必要な処理を柔軟に記述でき、cookieやローカルストレージへのアクセスも簡単に行えるのに対し、Next.jsだとそういったことが制限されている印象を持ちました。
   2. Next.jsの場合、サーバーサイドだと getServerSideProps でやり、クライアントサイドだと 共通で使うコンポーネントを作って対応したりと、うまく構築できない印象があります。（middlewareも何か"これじゃない感"がありました。）
2. コンポーネントへのプロパティの引き回しが煩雑になる（例: タイトルタグ等のメタタグの編集方法が煩雑）
   1. Nuxt.jsの場合、head関数をうまくページごとにオーバーライドしてあげることで、簡単にタイトルタグ等を出しわけできるのですが・・Next.jsの場合はheadを生成するコンポーネントを自作して、そこにうまくプロパティを引き渡してあげる必要がありそうなので、煩雑になってしまいました。
   2. タイトルタグ以外の場合でも、「global stateに定義するのもちょっと・・」と躊躇を覚えるものはすべてプロパティとして定義してコンポーネントに渡すのですが・・それが思ったより煩雑になるケースがあります。
3. コンポーネントの可読性がVueほどは良くない（良かった点のNo.4との対比にはなってしまいますが・・・）
   1. コンポーネントが書きやすい反面、htmlに到達するまでのjavascriptの行数が長くなりすぎて可読性を落とすケースがありました。（Vueだと computedプロパティに切り出されていて、コードを分離しやすい部分がありました）
   2. Vueだとデザイナーはなんとか触れる反面、React系はより厳しいかなという感じが出てきてしまいました。（classもclassNameとかになってたり、より生のhtmlから離れていってしまっている印象があります。）
4. 挙動に理解に時間がかかるものがある
   1. useEffect や useSWR など、挙動を理解するまでに何回かバグるのが必須のものなどもあり、ちゃんと使えれば便利なのですが・・ちゃんと使えないとハマってしまうものがありました。

以上です。

今後はNext.jsの活用箇所を増やしていきつつ、Nuxt側も折りを見てNuxt3に移行していこうと思っています。