この記事では、Webサービス（画面部分）を新規に開発するときの
技術選定について、個人的なベストプラクティスを紹介する。
前提：筆者のFE技術に関する解像度
最初に、筆者の各ツールに対する解像度を共有しておく。
今回の記事は網羅性・客観性を欠くため、
これを読んだ人に前提条件を伝え、判断材料にしてもらうという意図である。
- Next.js、Nuxt.js：実装経験あり
- Astro、Remix：最近実装し始めた
- WordPress：保守運用経験あり
- STUDIO、Wix、ペライチ：遊びで触っただけ
パターン別技術選定
①シンプルなLP作成
結論
STUDIO、Wix、ペライチなどのノーコードツール
理由
- 動きが少ないページであればプログラミングする必要がない
- ノーコードの方が手早く作れて学習コストも低い
- テンプレがあるので、デザインを一から考える必要がない
②こだわったLP作成
結論
シンプルなHTML、CSS、JavaScriptで書く
理由
- ①で挙げたノーコードツールでできないか検討し、どうしてもできないものがあれば自前で作る必要性が生まれる
- フレームワークやライブラリなどを入れても過剰なだけの可能性が高いので、基本的には素のHTML、CSS、JavaScriptを使ったほうが効率が良い
③更新頻度は低いが、コンテンツの量が多いブログ、カタログのようなサイト
結論
SSG（静的サイトジェネレータ）の仕組みを使って、静的ページを自動生成してデプロイする。
具体的にはAstroを使う。
理由
- プログラムが動くサーバーを使うより、コンテンツをただ配置するだけの方が安上がりである
- 後述するがNext.jsやNuxt.jsのSSG機能を使うにはコストが割に合わない
- AstroはReactやVueのようなコンポーネント志向で書けるのでReactやVueをやったことがあればそこまで学習コストは高くない
④CMS（コンテンツマネジメントシステム）を作りたい場合
外部APIにリクエストするなどのカスタマイズが必要ない場合を想定。
結論
WordPressを採用する。
理由
- WordPressは導入するだけで「コンテンツ表示画面」と「コンテンツ管理画面」両方入っているのが嬉しいポイント
- APIリクエストの実装が不要かつ、コンテンツを頻繁に書き換えたい場合に導入コストのバランスが良い
- デフォルトでデザインも豊富であり、知識があれば細かいカスタマイズが可能
⑤コンテンツの更新頻度が高く、WebサイトというよりはWebサービスを作る場合
裏側にAPIがしっかり存在するパターン。
結論
シンプルなSSR（サーバーサイドレンダリング）のアプリケーションを構築する。
フレームワークはRemixを使う。
理由
- 動的コンテンツを表示するには、特に理由がなければSSRが良い
- RemixはReactが使えるSSR特化のフレームワークのため、Reactを触ったことがある人なら学習コストはかなり低い
- Next.jsとNuxt.jsを避けた結果、Remixが良いという結論である
Next.js、Nuxt.jsを採用しない理由
ここまでの選定基準を見た読者には
「Next.jsやNuxt.jsは採用しないのか？」という疑問が生まれたと思う。
数年前は選択肢に入っていたが、以下の理由によりもう選んでいない。
理由①：機能が過剰であり、学習コストが高い
上記のスライドで述べられていることが全てではあるが、
特にNext.jsでは過剰な機能が増えすぎている。
「シンプルなWebサービスを作りたいだけなのに、余計な機能のことまで理解して実装しなければいけない」という苦労を筆者は経験してきた。
最近のアップデートを見るとEdge Runtimeなどを取り入れ、レンダリングの速さにこだわりを感じる。
一方で、一般的なWebサービスにおいては
フロントエンドの速度を改善するよりも先にデータベースやAPIの速度改善をしたほうが良いケースがほとんどのため、
個人的には「フロントエンドが速い」ことにあまり価値を感じていない。
理由②：サーバーサイドとクライアントサイドどちらで実行されるか分かりにくい
例えばNuxtにおいて、useFetch()などを用いてAPIリクエストを行う場合
デフォルトでサーバーサイドとクライアントサイド両方で実行される。
実務においては、
「これは機密情報を扱うからサーバーサイドで実行する」や
「ここはシームレスなユーザー体験のためにクライアントサイドで実行する」など
しっかり理由がある上で実装することがほとんどである。
つまり、どちらで実行するか意識している開発者にとって
明確に実行環境が分離されていない設計は分かりにくいだけである。
ここを十分に理解していない開発者が
「本来はサーバーサイドで処理するべき機密情報を、クライアントサイドで処理してしまったことで
ブラウザに情報が漏洩する」
という事故も容易に想像がつく。
Nuxt.jsを例に取ったが、Next.jsでも同様の分かりにくさは発生している。
SPA（シングルページアプリケーション）は？
筆者のSPAに対するスタンスは
「SPAでなければならないビジネス上の理由がない限り採用しない」である。
SSRと比較して、SPAは技術的に複雑度が増加するためだ。
- SPAには「データ取得前 / ロード中」というパターン考慮が必要
- クライアントサイドでの状態管理が増える
- URLを動的に変えるかどうか問題
SPAに対して相当なこだわりがない限り
「このWebサービス、SSRで十分じゃね？」という結論になることが多いだろう。
必要な場所でReactやVueの非同期処理ができれば十分だと感じている。
まとめ
つい最近まで「Next.jsが一番良い」と考えていたぐらいなので
この記事も1,2年経てば役に立たないものになるだろう。
ただし、筆者の判断基準はしばらくの間変わらないだろう。
- 「ディレクトリ構成=パス構成」になるルーティングができる
- サーバーサイドとクライアントサイド処理の分離ができる
- コンポーネント志向による部品の再利用性がある
- TypeScriptが使える
- 基本的にノーコードサービス→SSG→SSR→SPAの順で検討する
