Next.jsの複雑化について思うこと
はじめてReactを触った時の率直な感想は
「こんな気持ち悪い言語が流行るわけない」
でした。
しかし、今やReactはフロントエンド開発の王となり、当たり前のように使われています。
そして、現在は
ReactベースのフレームワークNext.js
が人気です。
それ以前に、Nuxt.jsというVue.jsベースのフレームワークが人気な時期もありましたが、ここ数年は猫も杓子もNext.jsを利用している印象です。
しかし、最近のNext.jsは独自実装と複雑化が進みすぎて、万人にはあまりオススメできないフレームワークになってきています。
2023年12月現在だと、小規模から中規模くらいのサービスを作るなら
Svelte(スヴェルテ)
が最もタイパの良い選択でしょう。
また、大規模なアプリを作る場合でも、Next.jsでなく通常のReactで十分です。
しかし、実際には
Next.js
を使っている現場をよく見かけます。
Next.jsを使うと、Next.jsとReactの両方の継続的なキャッチアップとアップデートが必要となるので、
ソフトウェア開発において最も重要な
顧客の問題解決に割く時間が減って
開発のための開発という
本質的でない効率の悪い開発に陥っているケースを見かけます。
なので、今回の記事では、これまでのReactとNext.jsの利用経験から、最近のNext.jsについて思っていることを記述します。
オレオレ実装が目立つ
今後のwebアプリのフロントエンド開発では、Next.js以外の選択肢を交えていく必要があると、私が本格的に考え始めたのは
App Directoryで導入されたNext.js13からです。
そして、この直感が正しかったと確認したのは
Next.js14で導入されたServer Actionsでした。
Next.jsの良いところは、version upをして最新の状態に保つだけで、色々な改善のメリットが得られることです。
しかし、
最近のNext.jsは
version upにかかるコストとversion upによって得られるメリットが釣り合わなくなっている
ように感じます。
今風にいうと
タイパが悪い
ということです。
また、Next.js自体の肥大化により、無駄なjsが生成されて容量が大きくなり、ネットワークの弱い環境でjsファイルのロードに時間がかかるようにもなってきています。
対応は可能なのですが、様々な対応対応で時間を取られるので、害悪であると思っています。
確かにApp Directoryを適用すれば、フォルダとファイル構成がわかりやすくなるので、大人数が参加する大規模なアプリでは、コードの品質がより安定するでしょう。
しかし、ほとんどの小中規模のwebアプリでは、決め事が多すぎると開発効率が落ちます。
Server Actionsに至っては、何がしたいのかわかりません。
ただでさえReact系のform処理はイケてないのに、さらに複雑化しています。
また、
‘use client’や
import "server-only";
のようなオマジナイを記載する仕様は、問題に対するエレガントな解決方法とは言えません。
そして、現在のNext.jsは
普段使わない機能をたくさん搭載した日本製のプロダクト
のようになっています。
今のNext.jsは
大規模アプリを作るのでない限り、無駄に開発工数が増えるだけで、世の中にある9割のwebサービスにとってはオーバースペックです。
また、ruby on rails以上に
僕の考えた最強の機能
が数多く実装されています。
これらの機能は確かに便利です。
しかし、フレームワークに依存しすぎてしまう懸念もあります。
開発においては、なんでもかんでもライブラリやフレームワークに任せればいいわけではありません。
特にコアな部分は、細かくコントロールできるようにしておかなければなりません。
開発者のフレームワーク依存が進みすぎると、フレームワークが使えない別の環境で同じような機能の実装が必要になった時、開発の基礎知識が身についていないので、フレームワークなしだと実装することができない
ということになりかねません。
実際、このようなケースを若いエンジニアが多い現場ではよく見かけるようになってきています。
今のNext.jsはこのような
ポータブルスキルが身につきにくいフレームワークとなっています。
最近のNext.jsを使っていると、このような懸念が浮かんできます。
バージョンアップとtypescript
上記に加えてNext.jsの大きな不満点は
バージョンアップが大変
なことです。
Next jsは最新の状態に保つことで、色々な改善のメリットを得られます。
逆に言うと
改善のメリットを享受するには、最新の状態に保って継続的なバージョンアップが必要になります。
しかし、肥大化したアプリのバージョンアップは手間のかかるタスクです。
大きなアプリであればあるほど、導入しているライブラリの数も増える傾向があり、このことはNext.jsのバーションアップをさらに困難にさせます。
また、その際、typescriptの型が合わなくてbuildができなくなるケースも頻発します。
Svelteがtypescriptから距離を置いたのとは逆で、Next.jsはtypescriptと癒着しています。
私はこれは悪手だと考えています。
私はSvelteの開発陣と同じ思想をもっていて
フロントエンド開発にtypescriptは不要で害悪である
と思っています。
ほとんどのwebアプリのフロントエンド開発は
JavaScript + JSDoc
で対応できます。
もちろん例外はあります。
しかし、その例外のためにNext.jsを使う必要があるかというと、「ない」とこれまでの経験から言えます。
また、世の中の極小一部の大きく成功しているサービスでは
「継続的にアップデートする仕組みを整えています」
とドヤ顔でアピールをしていますが、
99%のサービスでは再現できません。
なぜなら、ほとんどのサービスは株主から求められている売上を向上させるだけで精一杯で
継続的なバージョンアップを整える仕組みまで構築する余裕がありません。
しかし、このような非現実的な仕組みの信奉者になるのは、若くて意識の高い将来を嘱望されているエンジニアだったりします。
彼らはslackに記事のリンクを張り、現状を変えるべきだと改革を提案します。
しかし、ほとんどの企業では、継続的なバージョンアップの仕組みを構築する時間も人材も取ることができません。
こうなると彼らは
「経営陣は技術者を軽視している」
と会社に対して不満を持ち、他の会社に転職していきます。
しかし、転職先でも
ほとんどの現場では、開発環境構築のドキュメントすらまともに整備されていないことがほとんどです。
つまり現実の開発では
改善のメリットを享受するためとはいえ、ライブラリを常に最新の状態に保つのは、ほぼ不可能
ということです。
なので、version upのたびに大きな変更が入るNext.jsは、使い勝手が悪いと思っています。
今後のNext.jsとの向き合い方
さて、ここまで多くのNext.jsの問題をあげてきましたが、
上記のことを勘案しても
Next.jsを今後は絶対に使わないという結論にはなりません。
理由は
現在、多くの開発現場ではNext.jsが主流だから
です。
Next.jsには、サービスにおいて最も重要な「需要」があるのです。
確かに現在のNext.jsの方向性はイマイチです。
しかし、他のフレームワークへの置き換えをするべきかといえば、Noです。
そもそもとして
技術負債が蓄積しているからゼロから作り直すという発想は間違いです。
技術は顧客にサービスを提供するための手段でしかありません。
ソフトウェアの世界の流れは早いので、新しい技術で作り直しをしている間に、サービス自体の賞味期限がきてしまいます。
なので
負債を解決しながら新しい技術を取り入れていく
ことが現実的な解になります。
具体的には
基本的にはNext.jsを使いながら、新規サービスや軸の違う機能追加開発等では他の技術を導入し、他の技術がうまく自分のサービスにはまったら既存のサービスを新しい技術に置き換えていくか決める
といった対応になるでしょう。
まとめ
長くなりましたが、結論を言うと
Next.jsは確かに便利なフレームワークだが、ほとんどのサービスはSvelteかpureなReactで十分である
typescriptを使わないと十分な品質を保てないのか考えよう
ということです。
楽しい開発生活を送ってください。