私がNext.jsを使用しない理由

Daichi Takayama (高山大地)

以下の文章は、執筆者のKent C. Doddsさんからの許可を得て翻訳したものです。

あなたはこれから新しいプロジェクトに取り掛かるのでしょうか。それとも、今手がけているプロジェクトを、より最新の手法でアップグレードしたいと考えているのでしょうか。または、現在使用している現代的なフレームワークに何らかの不満を感じ、他の選択肢を模索している状況なのでしょうか。どのような状況であっても、どの道を選ぶかという決断は重要になってきます。

現代的なフレームワークの選択肢は多岐にわたります。今すぐに選択を迫られているわけではないのかもしれませんが、将来的な市場価値や生産性を考える上で、どのフレームワークを学ぶかを考えることは重要です。

2020年、私はリリースされたばかりのRemixを使い始めたところ、非常に気に入りました。そのため、1年後にはその開発会社に入社し、コミュニティを立ち上げる手助けをしました。その後、10ヶ月で退職し、EpicWeb.devでのフルタイムの仕事に専念することにしました。ここでは、フルスタックアプリケーションの構築に必要な知識を人々に教えています。その中心となるのがRemixです。RemixはフルスタックのWebフレームワークで、Webアプリケーションの開発における課題を解決することを目指しています。これはNext.jsとも似ています。

Next.jsがRemixの代替オプションとして存在する中で、なぜ私がEpicWeb.devでのフルスタック開発の教育において、Next.jsではなくRemixを選んだのかという質問を頻繁に受けます。そのような質問をする方は、恐らく私が先に述べたシナリオのどれかに直面しているのでしょう。この記事は、そのような方々に向けたものです。

私はソフトウェア開発の前向きな側面に焦点を当てることが好きです。「Remixを選ぶ理由」というタイトルで記事を書き、Remixの魅力について語る方が好きです（実際、そのような記事はすでに書いています）。しかし、多くの方が特にNext.jsに関して私に質問してきたため、こちらの記事を書くことにしました。

この記事を書く目的は、Next.jsを批判することではありません。私は、Next.jsに関して持つ個人的な見解と経験に基づき、正直な意見を述べたいと思っています。Next.jsについて否定的な意見を聞きたくない場合は、ここで読むのをやめて、外に出て自然でも感じることをお勧めします。

話を進める前に、私がこちらの記事を掲載しているサイトは、Next.jsで作られているという事実を認識しておく必要があります。ブラウザのコンソールで確認すると、__remixContextではなく、グローバルな__NEXT_DATA__変数が見つかるでしょう。これは、EpicWeb.devサイトが、何年にもわたりNext.jsを使用してソフトウェアを構築してきたチームによって作られたものだからです。

この事実は私たちが話し始める前にもう一つ重要なポイントを示しています：

どのツールを使うかは、おそらくそれほど問題ではない。

あなたが選ぶツール自体は、望ましい成果（すばらしいユーザーエクスペリエンス）を達成するためのツールの使い方のスキルと比べると、それほど重要ではありません。

この記事では、なぜ私がNext.jsを使わないのかという理由について話しますが、それは、Remixが優れたユーザーエクスペリエンスを生み出すのに適したツールだと私が考えるからです。しかし、もしあなたがNext.jsを使っているとしても、それがあなたが負け犬であるとか、悪人であるという意味ではありません。（ただし、私はあくまでRemixを使った方が効率的にるし、幸せにもなれると思っています。そうでなければ、こんな記事は書きません。）

さて、私はもう長い間Next.jsフレームワークの外部の人間でした。自分でNext.jsを使って何かを開発してからは随分と時間が経ちました。しかし、私の意見を無知だと却下する前に、この記事が多くの人々の実際の経験と共鳴していることを知っておくと良いでしょう。彼らの経験も同様に無視することになるので、私はそれをお勧めしません。

また、私はNext.jsの進化を追い続け、他人の体験談も耳にしています。過去のウェブ開発者としての経験から、フレームワークが取るアプローチに対する直感を持ち合わせており、それが私の感覚と合致しない部分をよく理解しています。

それでは、これらを踏まえて、なぜ私がNext.jsを使わないのかを説明していきます。

Webプラットフォーム

私は10年以上にわたり、HTTPを介してさまざまなものを展開してきました。デスクトップやモバイルのネイティブ開発にも手を出しましたが、私の本当の居場所はウェブ上にあると感じています。簡単な話を通じて、ウェブプラットフォームを取り入れるフレームワークに関心を持つべき理由を説明したいと思います。

数年前、Reactを使っていた時、Reactコンポーネントのテスト標準とされていたenzymeに対して不満を抱いていました。話を短くすると、私は Testing Libraryの開発を決めたのですが、これは現在、Reactや他のUIライブラリにおいて推奨されるテストユーティリティになっています。

enzymeとTesting Libraryの主な違いの一つは、enzymeがレンダリングされた要素との対話のために、多くの（過剰に）便利な（しかし危険な）ユーティリティを備えたラッパーを提供していたのに対し、Testing Libraryは要素自体を直接提供したことです。これを一つの原則にまとめると、Testing LibraryはプラットフォームAPIをラップするのではなく、それを露出しています。

このアプローチの主なメリットは移行可能性です。標準APIに焦点を当てることで、Testing LibraryはこれらのAPIに人々が慣れるのを助け、それが他の作業にも役立ちます。さらに、標準APIを使用する他のツールのユーティリティは、特別なアダプターを必要とせずにTesting Libraryと統合でき、その逆も同様です。

確かに、すべてのライブラリには独自のAPIがあります。たとえばTesting LibraryにはfindByRoleがあり、その入力を理解する必要があります。しかし重要なのは、それが直接DOM上で動作し、DOMノードを返すということです。APIを隠すのではなく、それらのAPIを露出することで、有用性と移行可能性のバランスを取っています。

Next.jsはenzymeと似たような側面があります。Next.jsにはリクエスト、ヘッダー、クッキーなどと対話するためのユーティリティがありますが、RemixではこれらのAPIを直接loaderやactionを通して提供します。Remixでは、これらの関数はWebフェッチのRequestを受け取り、Responseを返します。例えば、特定のヘッダーを設定したJSONを返す方法を理解する必要がある場合、RemixのドキュメントではなくMDN（デファクトスタンダードのウェブプラットフォームドキュメント）を参照します。このような事例は数多くあります。Remixを使いこなすほどに、ウェブに関するスキルも向上していき、その逆もまた然りです。

Next.jsが静的ビルド時間に問題を抱えていた時、ウェブプラットフォームのStale While Revalidate Cache Controlディレクティブを推奨する代わりに、同じ目標を達成するためにIncremental Static Regeneration (ISR)という複雑な機能を開発しました（彼らのドキュメントでSWRと同じことを達成すると説明しています）。

Angular.jsからReactへの移行時、Angular.jsに関する多くの知識を捨てました。Angular.jsを習得するために投じた時間は大きな無駄だったと感じました。私は二度とそのようなことが起きないことを望んでいます。そのため、ユーザーエクスペリエンスの観点から、私が望むものだけでなく、ウェブ開発のあらゆる場所で使えるスキルを提供するフレームワークに焦点を合わせることを好むわけです。

独立性

OpenNextはご存知ですか？もし聞いたことがなければ、こちらが自己紹介文の引用（翻訳版）になります：

OpenNextは、Next.jsのビルド出力を取り、任意のサービスとしての機能プラットフォームにデプロイ可能なパッケージに変換します。現在、AWS Lambdaのみがサポートされています。

Vercelは素晴らしいサービスですが、すべてのインフラをAWS上に持っている場合、Vercelは適切な選択肢ではありません。AWSアカウント内でホストすると、バックエンドとの統合が容易になり、Vercelを使用するよりもはるかにコストが抑えられます。

Next.jsは、RemixやAstroと異なり、サーバーレスを用いた自己ホスティングの手段を提供していません。Nodeアプリケーションとして実行することは可能ですが、Vercelでの動作とは異なります。

OpenNextは、Next.jsがVercel以外でのデプロイが難しいということに対応するために存在しています。

もちろん、道徳的な判断を下すつもりはありませんが、会社が自社のホスティングオファーを魅力的に見せるための動機は理解できます。しかし、それがNext.jsをどこでも簡単にデプロイできるようにすることの優先度を下げる原因になっているのは明らかです。

NetlifyチームはNext.jsをサポートするために、そしてNext.jsの変更に対応するために、かなりの時間を費やしていることがわかっています。他のインフラストラクチャホストがフレームワークのアダプターを構築することは理にかなっています（VercelがRemixのアダプターを管理しているように）。しかし、これらのホストからの情報によると、Next.jsは特にサポートや維持が困難であるとのことです。

また、個々の開発者からも、Next.jsを通常のNode.jsアプリケーションとして自分でホストするのが非常に面倒だという話をよく聞きます。興味深いことに、この情報が最初に公開されたとき、Next.jsを単にDockerコンテナに入れて日々を過ごしているという人もいました。それが彼らにとって上手くいくのであれば、それは良いことです。

しかし、Next.jsとVercelの境界線が曖昧であるため、Vercelでデプロイしていない場合、実際にはNext.jsのドキュメントに記載されているフレームワークとは異なるものを使用しているという問題が存在します。これらの違いが何なのかは常に明確ではないため、Vercelにはそれに注力するインセンティブがありません。

Vercelの現在のアプローチが正しいか間違っているかは議論の余地がありますが、もしVercelの価格設定や他の問題があなたにとって問題になるなら、Vercelから離れることもまた問題となります。これは結局のところ、インセンティブに関する問題に戻ってきます。

残念なことに、Vercelの価格設定が多くの人にとって大きな問題になっていると聞いています。

さらに、Vercelはまだ利益を上げていないと言われています（8年経過してもなお積極的に成長していますが、その1顧客あたりの採算性には疑問があります）。これは、すべてのリソースをVercelに依存することに対する大きな懸念を抱かせます。

Remixは初めから、JavaScriptが実行可能なあらゆる場所でデプロイができるよう設計されていました。これは、標準に対する強い焦点によって大いに支えられています。私はRemixのこの特徴を非常に高く評価しています。

RemixはShopifyによって買収されましたが、Shopifyはこのプロジェクトを素晴らしく運営してきました。RemixチームはShopifyに加わった後、ShopifyがRemixを使用しているさまざまな環境（マーケティングページ、電子商取引、内部および外部アプリケーションなど）のおかげで、より迅速に開発を進めることができました。さらに、Shopifyに買収されたことで、Remixチームはフレームワークを利用して収益を上げる方法を考えることなく、フレームワークに全力を注ぐことができるようになりました。

Next.jsがReactを食い尽くしている

MetaがReactを所有していることに関して、常に少し不安を感じていました。しかし、Vercelが多くのReactチームのメンバーを雇用していることが、私にとって状況を改善することはありませんでした。それ以降、Reactチームは以前ほど協力的であるとは感じられなくなりました。

個人的には、VercelがNext.jsとReactの境界線を曖昧にしようとしているように感じています。特に、サーバーコンポーネントやサーバーアクションなどの機能に関して、Next.jsとReactの違いについて混乱している人が多いです。

Reactがオープンファウンデーションに所属していれば、もっと安心感があります。しかし、それが現実にならない限り、少なくともVercelに加わった以降、彼らがより協力的になることを望みます。

これはNext.jsにとって利点となるかもしれません。少なくとも、Reactとの緊密なコラボレーションから恩恵を受けています。しかし、私の経験では、協力的でないチームはそのソフトウェアの品質にとって悪い兆候です。

特に、RedwoodやApolloのメンテナーは、この協力不足による大きな問題に直面しています。

アップデート：この記事を公開したと同時に、ReactチームのデベロッパーアドボケイトのMatt Carrollが私に連絡を取りました。これは良い兆候だと思います！

ユーザーを使っての実験

Next.jsチームが実験的な機能を安定版としてマーケティングするという疑わしい決定に対し、私は大きな懸念を抱いています。Next.jsが安定版としてリリースしている機能が、実際にはReactのカナリアリリースに含まれていることは、正直言ってかなり興味深く、同時に悲しいことです。

「カナリア」という言葉の意味をご存知でしょうか？それは先駆け種を指し、人間に迫る危険を事前に警告するために使用される種のことを意味します。つまり、Next.jsは自社製品にカナリア機能を組み込み、それを安定版として扱い、ユーザーに提供しているのです。これにより、実際にはあなたのアプリが先駆け種となってしまっています。これを単なるメッセージングの問題と見ることもできますが、Next.jsのApp Routerを試した多くの人から、その経験があまり肯定的ではなかったという話を聞いています。これは主にその不完全さに起因すると思われます。彼らがカナリアの役割を果たしています。

App Routerを使用して素晴らしい経験をしていると報告する人もいますが、私は多くの人が感じている楽しさは、pagesディレクトリの制約から解放され、ネストされたルーティング機能を得られることから来ていると確信しています。これは必ずしもカナリア機能から来ているわけではありません。

確かに、Reactサーバーコンポーネントはとても魅力的で、これが本番環境で利用可能になるのを楽しみにしています。それによってRemixは多くの作業を軽減することができるでしょう。

これらの問題についてさらに詳しく知りたい場合は、このスレッドをご覧ください：

多すぎるマジック

驚き最小の原則という概念はご存知ですか？以下のように紹介されています：

システムのコンポーネントは、ほとんどのユーザーが期待する通りに振る舞うべきであり、そのためにユーザーを驚かせたり困惑させたりしない。

この考え方は「Webプラットフォーム」のセクションにも適用されるかもしれません。なぜなら、人々を驚かせない最も良い方法は、できる限りウェブプラットフォームのAPIに従い、ソフトウェアが行う「マジック」の量を最小限に抑えることだからです。マジックは素晴らしいものですし、ボイラープレートを減らすことに役立ちますが、何が起こっているかを明確に理解するために、そのマジックを意識的に選択したいと思います。それが自動的に行われるのではなく。

Next.jsはこの原則に多くの方法で違反しています。その一つの例として、自動キャッシングを追加するためにグローバルなfetch関数をオーバーライドするという決定があります。これは私にとって大きな警告信号です。このような決定があると、Next.jsを採用した場合にどのような意外な問題が生じるかと懸念されます。

MooToolsの時代から、プラットフォームの組み込み機能をオーバーライドすることが問題を引き起こすことは知られています（例えば、String.prototype.includesが存在するのはString.prototype.containsではないためです）。このような行為はウェブプラットフォームの未来に悪影響を及ぼすだけでなく、何かがうまく機能しない理由をデバッグする際に「Next.js版のfetch」と「ウェブプラットフォーム版のfetch」の違いを探る必要があるということも意味しています。

複雑さ

Next.jsが過度に複雑になっているという話をよく聞きます。これは「多すぎるマジック」とも関連しています。Reactにはサーバーアクションや、新たな実験的な「汚染」APIがありますが、これらは多くのネタになっています（私も「taint」のもう一つの意味を知ることになってしまいました🤦‍♂️）。

Reactがミューテーションに対する組み込みサポートを追加することには興味を持っています。しかし、ウェブフォームの動作方法のセマンティクスを変更することには懸念を感じています。これらの要素は複雑さを増すことになります。

私は、Remixチームが私と同じ原則を共有する人々によって率いられていることを高く評価しています。このような機能が導入される場合でも、複雑さを増す道を進まないようにするでしょう。実際、Remixチームは将来的にAPIの全体的なフットプリントを削減することにコミットしています。これは私の次のポイントに繋がります。

安定性

Next.jsは現在バージョン13に達しています。一方で、React Router（Remixと同じチームが開発）はずっと前から存在しており、現在はバージョン6です。Remixは約2年間バージョン1のままで、1ヶ月前にようやくバージョン2へと移行しました。これは、Remixチームが安定性に重点を置いているおかげで、ウェブフレームワークの中で最も退屈なメジャーバージョンアップとして知られています。

Next.jsチームがアップグレードパスを簡易化するためにコードモッドに多大な努力を注いでいることを認めます。フレームワークが時間と共に進化する必要があることも理解しています。しかし、Next 13でNext.jsチームが導入したものに関して不安定さを感じる人が多いことも事実です。カナリア機能をラップして安定版と称することには納得がいきません。

今年の初め、Remixチームは「フューチャーフラグ」という戦略を用いて、バージョン2の機能をバージョン1のオプトイン部分としてリリースする計画を発表しました。これは非常に上手く機能し、多くのアクティブなRemixアプリが1日未満でアップグレードされました。

Remixチームが安定性に焦点を当てていることは非常に重要です。これが、過去にReactサーバーコンポーネントのサポートを実装しなかった背後にある理由の一つであり、またReact Routerが8年間で唯一の破壊的な変更を受けた理由でもあります。

安定性は、開発者とそのアプリケーションにとって非常に重要な要素です。新しいバージョンにアップグレードするたびにコードを更新し、混乱を招くのはストレスフルな経験です。特に影響力のあるウェブフレームワークについては、そのような不安定さは避けたいものです。Remixの安定性は、開発者にとって非常に有益な要素であり、信頼性を提供しています。

能力

この記事はNext.jsとRemixなどの他のフレームワークの機能と能力を比較するものと予想されていた方も多いのではないでしょうか。しかし、実際には、両方のフレームワークで素晴らしいアプリケーションを構築できます。私が伝えたいのは、機能よりも能力が重要であるということです。個人的には、Remixを使用することでさらに幅広い成功が得られると感じていますが、それについて詳しく説明するつもりはありません。多くのことは主観的な要素を含んでいます。

Remixチームが「Remix vs Next.js」の質問に答えるためにNext.jsのeコマースデモを書き換えたとき、Remixはより少ないコードでより良いユーザーエクスペリエンスをもたらすことが非常によく示されました（これはユーザーエクスペリエンスにおいて重要な要素です）。それ以来、Next.jsはApp Routerを使用するよう更新されました（安定版と呼ばれていますが、既に述べたようにカナリア機能に依存しています）ので、もう一度比較する価値があると思います。Remixもその記事が書かれて以来、順序を越えたストリーミングなどの新しいテクニックを学びました。

結論

あなたは私が言ったことに同意するかもしれませんし、反対するかもしれません。不公平だと思うかもしれませんし、もっと多くまたは少なく言うべきだったと思うかもしれません。それはあなたの権利であり、𝕏、YouTube、Twitchなどでこの件に関する意見を共有していただければ幸いです。ただ、私が経験したこと否定する場合、この記事が真に共鳴した多くの他の人々の経験も否定していることを覚えておいてください。

VercelのDX担当VPであるLee Robinsonが、彼のブログに思慮深い返答を投稿しています。読んでみる価値があるかもしれません。Leeと私は友人であり、私は彼をとても尊敬しています。その投稿は私が持ち上げた多くの懸念に触れていますが、個人的には私の懸念を満足させてはいません。

私は単に、Next.jsではなくRemixを推奨し、教える理由を共有したかっただけです。次に誰かが私に同じことを尋ねたとき、この記事を指し示すだけで済みます。

要約すると、私は両方が非常に能力のあるフレームワークであると感じていますが、Remixはソフトウェアを長期的に保守可能で楽しいものにする上での私自身の感覚とより一致しています。また、これら二つのフレームワークの間では、EpicWeb.devで学んだ知識が、Next.jsを教える代わりにより移行可能であるとも感じています。

2023年の夏に、私は8週間にわたるEpicWeb.devワークショップシリーズのライブプレゼンテーションをホストしました。出席者の一人であるGwen Shapiraが数ヶ月後に私に言いました：