はじめに

こんにちは、初めての投稿になります。
フロントエンドエンジニアとして職務につき早7年目になります

僕の周りでは徐々にNuxt3を使った案件や、
Vite+Vue3にAPIサーバとしてのLaravelを置く構成が増えてきました。

ただ一方でLaravelのテンプレートエンジンであるbladeに、
部分的にVueコンポーネントを採用するようなパターンも依然として多くあります。

両方とも有力な選択肢だと思いますが、
今回は1人のフロントエンドエンジニアとしてどちらだと嬉しいかという観点でお話したいと思います。

以下の前提で話を進めます。

また個人的な意見を多く含んでいるためポエムとしてご鑑賞頂けたら幸いです。
それでは始めましょう！

SPA + API開発のメリット

タイトル書いただけで何番煎じだよ・・と自分でも思っちゃったので、とりあえずChatGPTに聞いてみましょう。最近は困ったらこれです。

ふむふむ、どれもUIUXを向上するのに非常に重要な要素ですね！
ですが今回はここに書かれていないものを1つ挙げたいと思います。

それはフロントエンドの責務に関することです。

サーバサイドのテンプレートエンジンに乗っかることが問題だと思う最大の理由は、
フロントエンドの責務が極端に狭められてしまうことにあります。

どういうことかご説明する前に、
近年のフロントエンドフレームワークが持つ性質として、
宣言的UIというのがあるので簡単にご紹介します。

宣言的UIとは
数式で表すとUI = f(state)
状態が変わればUIも変わることを端的に説明する文脈で用いられます。

一方でこれは個人的な解釈ですが、
状態をどれだけ大きなスコープで持てるかがUIへの影響度そのものに直結するとも言えます。

どういうことかご説明します。

サーバのテンプレートエンジンに乗っかるということは、
フロントエンドの責務がテンプレート部に限定されるということで、
同時に状態のスコープとしてもページ内に閉じられます。
それはページより外の状態にも、状態を変えるロジックにも基本的にアクセス権がないことを意味します。

一方でSPAにするということは、
フロントエンドの責務を通信を除くアプリケーション全体まで拡げるということを意味します。

ルーティングやアプリケーション内の状態管理、ビジネスロジックなど含め、
通信を除いたあらゆる状態がフロントエンド側で制御することが出来るようになるため、UIに対する自由度に制限がありません。

・・・話していること難しいですか？
簡単に言っちゃうと、もっとフロントで好き放題やらせろということです。

UIの状態の多くはサーバ由来の変数で判定することになり、
初回レンダリング以降の画面要素の更新は基本的に難しいです。

モダンなJSフレームワークであれば状態をランタイムで保持し
状態の変更をトリガーに画面要素を再レンダリングするのが当たり前なのですが、
それが出来ないため手続き的な対処を迫られます。

そこでは死んだ目をしながら、
要素を取得してクラスを当て替えするフロントエンドエンジニアが観測できるでしょう。

サーバーサイドテンプレートを選んだ時点で、
下のお世話から何から何までサーバサイドにお願いすることになります。
(ページの用意、ルーティングの繋ぎ込み、テンプレート内で必要な変数の用意など)

それだけではありません、UI設計がサーバ実装に依存するリスクがあります。
例えばカレンダーのUIがあるとします。

月選択をするとURLにクエリが付いた状態でページリロードが走り、
サーバからは選択した月のデータが送られてくるという設計です。

お客さんから「毎回ページリロードするの見栄え悪いんだけど・・」と言われても、
非同期で取ってくるような設計に変えるにはサーバ側の対応が必要です。
フロントは渡ってきた情報を加工することくらいしかしませんし出来ないのです。

そこではUIの理想と現実に葛藤するフロントエンドエンジニアが観測できるでしょう。

再三になりますが、
サーバのテンプレートエンジンに乗っかるということは、
フロントエンドの責務がテンプレート部に限定されるということです。
SPAと違い出来ることがそもそも少ないです。

そこではscopedの庇護下から離れ、日々グローバル汚染に怯えながら、
クラス名を考えるだけで精一杯なフロントエンドエンジニアが観測できるでしょう。

おわり。