Nuxt + TypeScript の環境でフロント～バックエンドまでトータル開発をしたのでその時の所感。

良かった所

コンポーネント単位の開発に順応しやすい(Nuxt)

1 コンポーネント内に Html・JavaScript・Css(Sass)が纏められているため、
他に派生しないような機能ごとの開発であれば全体を理解しやすくプロジェクトに入りやすいと思う。
バックエンド開発者で JS について理解が薄めでも基本的にはライフサイクルフックと methods だけ理解してもらえば
データ処理はバックエンドに任せ、取得したいタイミングのライフサイクルフックで API を叩いてあげればあまり難しいことは考えなくてもいい。

多少のコンポーネント数であれば、JavaScript 部でコンポーネントを取り込んで html にパーツとして配置するだけで良いので
基本的には JS の imoport 部を見て判断するだけでいい。上記の JS の記述と合わせると基本的には JS 部分を見るだけでどれくらいの役割を持っているか判別できるため簡単。

ルーティングがわかりやすい(Nuxt)

pages への配置が url ルーティングと一致しているためマイクロ構成のサービスであればかなり開発が楽だった。
基本的には pages 以下フォルダを使って開発していけばいいため、ディレクトリが散らかることなくコンパクトに作業することができた。
ルーティングについては Next の方も同じような方式をとっているため Nuxt の強みではないけど、
Nuxt を使うということのメリットではあるので多ページになるようなサイト構築する場合は素の Vue ではなく最初から Nuxt を使う一度だと思う
(素の vue はどの層のメリットになるんだろう……学習層とか後入れ？)

悪かった所

共有コンポーネントが多くなればなるほど複雑になる(Nuxt)

コンポーネントの導入については規約でケバブケースとなっているため、html 部のコンポーネントを探すのが少し面倒だった。
ここに加えてコンポーネントが複雑になると A から B、B から C への props 渡しを考える必要があり、データ管理が非常にわかりにくくなる。

ある程度時間が取れるような PJ ではない場合、Node 主体ではない Nuxt 開発だとどこでエラーが出てるのかの切り分けが滅茶苦茶面倒になるため、
よりシンプルな設計であることが求められて地味に難易度が上がるのかなと思う。
拡張性を考えるならコンポーネント内での副作用は避けたいけど、分割すればするほど Nuxt というか.vue ファイルの良さが失われるような……。
分割数が増えれば増えるほど個人的には JS/TS を使い一元管理してシームレスに扱える Nuxt(React)のが便利かなーと思った。

グローバル this に Any が入ると更に面倒になる(TypeScript)

これは参加した PJ の設定感のせいかもしれないが、型を設定していてもグローバルに新規変数を設定することができ、
その変数には型がなかったせいで Any 型を対応する羽目になった事があった。オブジェクトについても型指定が厳密にできていないと
Any 許容されてしまっている箇所が多かったりで開発時にエラー切り分けが面倒だったことがあった。
その際見直してみた所 JS 部での片付がされていなくてもビルドが通ってしまっているモジュールがいくつか見られたため、
TypeScript は導入されているけどテンプレートレベルでの使用が任意になっている感じだったのでそりゃ駄目だろっていう……

型導入するなら当たり前だと思うけど全体で使わないと意味がなくなっちゃうのでルール化・徹底は必須だよね。
途中から入った PJ でこんなことがあったらきちんと声を上げるか影響がない範囲であれば諦めましょう。そのチケットが飛んできたら泣きましょう。

単純に超デカい行数になるため読み辛くなる(Nuxt)

単純に.vue ファイルが読み辛い。1 ファイルにまとめようとすると Register ページなんて 1 万行超えたりすることはザラだし、
かといって分割するとモジュール内モジュール内モジュールになって複雑性が増したりでどっちを取るか問題になってくる。
加えて上記型問題のように TS が入っている前提で開発していたら子モジュールに型定義が入っていなかったりすることを考えると……(実際あってめちゃ辛かったので)

Nuxt はコンポーネントについては結構切り分けてったほうが開発しやすい印象だけど、JS 部が長くなればなるほど切り分けるというよりは
ユニークな処理になってくるのでバックエンド側でほぼ完結させて、フロントは表示するのみくらいの規模感に向いているような印象だった。
Java で Spring 使って業務アプリ開発するよりは開発体験がいいし、環境構築とかビルドの面から見てもやりやすさはあったのでそういう意味ではマシだったのかなと。
自分がいた所は結構肥大化した PJ になってたから大変だったのもあるのかもしれない。

所感

書き出してみたけど……Nuxt というよりは設計・ルール決めが甘いのが問題では？という感覚になった。
Nuxt については Next 等 React 系列よりもやはり1ファイルで完結するという触れ込みがありレガシー環境からの脱却プロジェクトで一番最初に選択されると思う。
手軽に導入できるけどコンポーネントが複雑になるにつれて設計・ルールの甘さがゴリゴリに効いてくるため、
内部にある程度わかっている人が多そうな React 系の方が大きめのプロジェクトになっても破綻はしづらいのかなと思う。

TypeScript を実務で使った初めての現場ではあったけどやっぱり型があると切り分けが早くなって、ビルド前にミスに気付けて開発体験的にはめちゃくちゃいい。
NodeJS の開発速度が個人的には好きだけど、型を導入して少し定義に時間がかかってもそれを取り返すメリットが有るから TS については全く文句がなかった。<b>TypeScript はいいぞ</b>