Next.jsとの比較

VikeはNext.jsには異なる点が3つあります:

1. VikeはUIフレームワークに囚われない。

   VikeはReactに完全に依存せず、ソースコードもReactへの依存はゼロです。Vikeは他のUIフレームワーク（Vue、Preact、Solidなど）と一緒に使うことができます。

   Vikeでは、Reactインテグレーションを実装し、完全にコントロールすることができます。例えば、Next.jsでは不可能な、Facebookと同じ方法（render-as-you-fetchストリーム）でRelayを使用することができます。

2. Vikeはサーバーやデプロイメントに囚われない。

   Vikeを使えば、サーバーを完全にコントロールでき、どのようなデプロイメント戦略も利用できます。

3. Vikeは本格的でありながらミニマル。

   すべての依存関係はViteと共有されるか （e.g. fast-glob）、完全/移行的に所有されます（e.g. @brillout/json-serializer）。 VikeをViteアプリに追加しても、軽薄な依存関係は追加されません。

   私たちは、Vikeが本格的なフロントエンドツールであると同時に、無駄なな課題やエラーを避けるというスイートスポットに当たると信じています。

このような構造的な違いに加え、Vikeは、Viteによる超高速HMR、 最先端のSPAサポート（特に今後の新しいVikeデザインによる）、ドメイン駆動型ファイル構造、最先端のコード分割（Vite/Rollupによる）、自動デプロイ同期、独自のフレームワークの構築などの機能を導入しています。

TurbopackはViteの超高速なDXテクニックの一部を再現していますが、まだ発展途上であり、Turbopackが本番に対応するまでにはしばらく時間がかかるでしょう。Viteを使えば、今すぐ光速なDXを使うことができます。

最後に、Vikeはコミュニティ・プロジェクトである。ビジネス上の利害が根本的に対立するフレームワークに依存するのではなく、コミュニティが主催し、コミュニティのために作られたコミュニティ主導のプロジェクトを利用しませんか？

サーバーやデプロイメントに囚われない

サーバーの観点から言えば、Vikeはどこでも（AWS、Vercel、Cloudflare、Deno Deployなど）実行できるミドルウェアに過ぎません。

Vikeを統合するには、Vikeのミドルウェアをサーバーに追加するだけです（Express.js、Fastify、Edge Worker、Serverless Functionなど）。

Vikeでは、アーキテクチャの最も重要な側面の1つであるサーバーとデプロイメントを完全にコントロールできます。

詳細の比較表

@patryk-smc と @redbar0nによる:

	Vike	Next.js
UI フレームワーク	すべて (React, Preact, Solid, etc.)	React のみ
コード分割とバンドル	可能	可能
HMR	可能 速い	可能, 遅い
SPA	可能	限定的
SSR
コントロール	フルコントロール	限定的 / ブラックボックス
レンダラー	可能、好きなだけ	一つのみ (_app.ts ファイル)
RSC (React サーバーコンポーネント)	可能, 部分的に	可能、実験段階
ルーティング
ファイルシステムルーティング	可能	可能
ドメイン駆動ファイルシステムルーティング	可能	不可
クライアントルーティング	可能	可能
サーバールーティング	可能	不可
ベースURL	可能	限定的
統合
HTTP サーバー	なし*、 自分で実装してください	カスタムサーバーは、注意事項とともに部分的にサポートされます[1][2]
Apollo Client with SSR	フルサポート	部分的にサポート
Relay with SSR	フルサポート	部分的にサポート
その他
Headコンポーネント	なし*、 react-helmetなどのツールを使用してください	あり、 next/head
Image component	なし*、 画像最適化ツールを用いてください	あり、 next/image
API routes	なし*、 自分のサーバーかRPCツールを使用してください	あり
Internationalization (i18n)	可能	限定的
デプロイの同期	可能	不可
独自のフレームワークを構築	可能	不可
デプロイオプション
Vercel	最低限の設定で可能	設定なしで可能
Cloudflare Workers	最低限の設定で可能	不可、 作業中
Node server (Docker, Heroku, Digital Ocean etc.)	最低限の設定で可能	制限はあるが可能
Caching (see own section above)	No*, if needed, use industry-standard caching**.	App Router caching, opt-out

(*) Vikeはデザイン上、そのような余分なものは行いません。 (**) キャッシングの業界標準的な方法としては、HTTP Cache-Control ヘッダーを使用してクライアントのブラウザでキャッシュすることがあり、さらにはサーバーサイドの前に配置された共有/公開の CDN キャッシュでも可能です。さらに、それ以上のキャッシングが必要な場合は、例えば Redis や Memcached を使用して、サーバーサイドにインメモリキャッシュを持つことも可能です。

ユーザーの声

@Axxxx0nより:

1. Vite (オンデマンドトランスパイル、ネイティブESM)による高速開発。
2. Next.jsには多くのサンプルが必要であり、Next.jsとライブラリを統合するためのライブラリが数多く存在します（たとえばnext-i18next）。Vikeなら、統合したいライブラリのドキュメントを読むだけでOKです。
3. Reactの新機能が登場したら、すぐに使い始めることができ、Next.jsチームが統合するのを待つ必要がありません。(ストリーミングAPI、サーバーコンポーネント、サーバー上のサスペンス、部分的なハイドレーションなど）。
4. Next.jsは、ビルド後に/publicディレクトリにあるファイル（ユーザーがアップロードした画像など）を読み込むことができません。
5. getServerSideProps()で、Next.jsはクライアントサイドのレンダリングをブロックします。
6. クライアントサイドのナビゲーション（Next.js - #23921）でデータ取得をバイパスすることはできません。
7. Next.jsはVercelプラットフォームを強力にプッシュしており、最近の機能アップデートに現れ始めています。Next.jsに沿った機能が優先される一方で、重要な修正は遅れています。
8. Next.jsはサーバーレスに傾倒しており、必要ないのに使い方が複雑になっています。

UIフレームワークに囚われない

Vike is completely agnostic to React and its source code has zero dependency on React. You can actually use Vike with any other UI Framework (Vue, Preact, Solid, etc.).

With Vike, you implement and fully control the React integration, which has many benefits. For example, you can use Relay in the same way that Facebook does (with a render-as-you-fetch stream) which isn't possible with Next.js.

Vikeでは、Reactを自分で統合します。つまり、もう少し定型文を書く必要がありますが、その代わりに柔軟性が増します。 You can even use vike-react to do it for you, and later when you need more control you can eject. Reactを自分で統合するため、お気に入りのツールを用いたフロントエンドの統合（データ取得、状態管理、認証など）を完全に制御できます。

たとえば、Next.jsでは不可能な方法でRelayやApolloを使用できます。

Relayは、（GraphQLを発明した）Facebookによって開発され、大規模に使用されている最先端のGraphQLクライアントである。YouTubeのビデオ 「Re-introducing Relay 」では、Relayの利点について詳しく説明しています。 多くのユーザーやスポンサーが、RelayとSSR Streamingを統合するVikeの柔軟性を活用しています。

Vikeにはクライアントサイドルーティング、HMR、ファイルシステムルーティング、プリレンダリング、データフェッチ、コード分割、レイアウト、i18nなどのフロントエンドフレームワークに期待されるものが全て含まれています。

デプロイメント/ホスティング非依存

Next.js

Next.js は、ホスティングプロバイダーである Vercel によって開発されました。したがって、自然に彼らの環境とインフラで実行されるように最適化されています。しかし、Vercel は スケールすると非常に 高価になる ことで知られています。 さらに悪いことに、Vercel の価格設定は誤解を招くものであり（開発者ごとの支払いは安く見えますが、制限を超えると非常に高価な料金を支払うことが多い）、 不透明（例えば、10人以上のチームメンバーがいる場合はエンタープライズプランが必要で、これは細かい文字に隠されています）、 非常に高価なイーグレス料金によってロックインされ、 理解が難しく、ほぼ予測不可能です。 このような価格設定は、大企業にとって論外です。

Next.js は Node.js サーバーとして自己ホスティングすることができますが、例えば Docker コンテナ内に配置することができます。しかし、Vercel 上での動作と全く同じではありません。 さらに、Next.js をサーバーレスまたはエッジアプリケーションとして自己ホスティングする（つまり、Vercel を置き換える）ことは、さらに悪化します。

問題の一例として、Next.js のサーバーアクションでは API エンドポイントを手書きすることがなくなります。これはバージョニングを明示的に制御する能力がないことを意味します。そのため、古いクライアントからのリクエストが失敗する可能性があります。Vercel は、Next.js 自体ではなく、彼らのデプロイメントインフラストラクチャでこれを解決しました。したがって、Next.js を使用しているが Vercel を使用していない場合、この大きな問題に自分自身で対処する必要があります。

このような困難により、オープンソースコミュニティは Open-Next.js の開発を行いました。これは、Next.js を一般的な Functions-as-a-Service (FaaS) プラットフォーム（特に AWS Lambda）上でのサーバーレスデプロイメントを容易にするプロジェクトです。これにより AWS との統合が容易になり、Next.js と Vercel の結びつきを減らします。しかし、これは頻

Vike

Vike を使用すると、サーバーを完全に制御でき、任意のデプロイ戦略を使用できます。

Vike はサーバーとデプロイメントに依存しないため、任意のホスティングプロバイダーや好みのサーバー/サーバーレス設定を使用できます。Vike は、最初からサーバーレスおよびエッジ互換性を考慮して構築されています。

サーバーの観点からは、Vike は単なるミドルウェアであり、Node.js に依存せず、JavaScript が動作する AWS、Vercel、Cloudflare、Deno Deploy、あるいはブラウザ内など、どこでも実行できます。

Node.js に依存しないサーバーでアプリを開発し、どこにでもデプロイできます。

また、アプリを事前にレンダリングして、本番サーバーの必要性をなくすことができます：あなたのアプリは静的アセット（HTML、JS、CSS、画像など）のみから構成され、GitHub Pages などの任意の静的ホストにデプロイできます。

ローカル開発のためには Node.js が必要ですが、Vite（Vike によって使用される開発・ビルドツールキット） の開発ランタイムは Node.js に依存しています。しかし、Vite のランタイムは本番環境では必要ありません。したがって、Vike のランタイムが Node.js に依存していないため、本番環境で Node.js に依存することはありません。

Vike を統合するには、サーバー（Express.js、Fastify、Edge Worker、Serverless Function など）に Vike のミドルウェアを追加するだけです。

Vike を使えば、ビジネスにとって重要な二つの側面であるサーバーとデプロイ戦略を完全に制御できます。

最小限で自己完結（依存なし）

Vike のすべての依存関係は、Vite と共有されているもの（例えば fast-glob）か、完全に所有されているもの（例えば、私たちは @brillout/json-serializer を所有しています）。Vike をあなたの Vite アプリに追加しても、不要な依存関係は追加されません。

私たちは、Vike が完全なフロントエンドツールでありながら、不必要な飾りや機能を避ける最適な点を打っていると信じています。

デフォルトでのキャッシング vs. オプトイン

Next.js

Next.js は、パフォーマンスとコスト削減のために、キャッシングを積極的に使用しています。サーバー負荷が少ないということは、アプリが使用するコンピュートリソースが少なくなり、Vercel の有料プランでお金を節約できるということですが、Vercel にとっては無料プラン（ほとんどの開発者が使用しているであろう Vercel のロングテール）での節約にもなります。

Next.js は、できるだけ多くのルートを静的にレンダリングする（可能な限り SSR より SSG）方向に傾いています。キャッシングはデフォルトで有効になっており（サーバーとクライアントの両方で）、それを無効にしたい場合は 明示的にオプトアウト する必要があります（よりハッキーな解決策を使用して）。

しかし、人々は積極的なキャッシングが悪夢であると見つけて、無効にするのが難しいと感じています。キャッシングは、アプリの間違った/古いビューを提供し、原因を探すために貴重な開発時間を費やすことになります。

ことわざにもあるように、 「コンピュータサイエンスで難しいことは2つだけ：キャッシュの無効化と名前付け。」 -- Phil Karlton

Vike

Vike は、デザインによりキャッシュを使用しないため、デフォルトではアプリが期待通りに動作します。キャッシングを使用したい場合は、多くの業界標準のキャッシングツールのいずれかを使用して、それにオプトインできます。

サーバーファースト vs. 詳細な作業分割

Next.js - サーバーファースト指向

Next.js は Vercel（ホスティングプロバイダー）によって開発され、サーバーに焦点を当てています。現在では、React レンダリングツリー内の全ての React コンポーネントを React サーバーコンポーネント（RSC）として解釈することがデフォルトになっており、これを望まない場合はオプトアウトする必要があります。

RSC を使用する場合、クライアントコンポーネントに変換したい各ブランチの開始時に React コンポーネントツリーにバンドラディレクティブ "use client"（クライアントバンドリングの開始）を挿入する必要があります。

サーバー指向のデフォルト設定は、クライアントの対話性がない大きな静的セクションから成る ウェブサイト には理にかなっています。RSC を使用すると、RSC の JS コードがサーバー上でのみ実行されるため（例えば、重いマークダウンライブラリを使用する静的サイトに役立つ）、クライアントサイドバンドルのサイズ（およびハイドレーション）が削減されます。しかし、RSC にはシリアライゼーションとパースのオーバーヘッドがあり、特別なルール（状態、コンテキスト、またはエフェクトなし）と多くの開発者が苦労する概念的なオーバーヘッドがあります。

全体として、Next.js がサーバー（およびデフォルトでの RSC とキャッシング）により傾いているという事実は、特に ウェブアプリ を構築しており、それがどんどんダイナミックでインタラクティブになることを期待している場合には、望ましいものではないかもしれません。

もし貴方のプロダクトが以下のいずれかである場合：

• アプリ に寄りかかっているよりも、サイト/ページ に寄りかかっている。
• データベースからの大量の動的に生成されたり頻繁に更新されるコンテンツを持っており、キャッシングが大きな利益をもたらさない場合。
• ポーリングや ライブUIの更新 を含むかもしれないデータローディングのための単一統一モデル を持っている。
• ローカル/オフラインファースト、および/または PWA。
• クライアント中心である典型的なネイティブプラットフォーム間でのコードの再利用（クロスプラットフォーム）、React サーバーコンポーネントが React Native 上でどのように機能するかが 優先されていない または非常に明確ではない。
• サーバーリソースの使用を減らし（スケーラビリティ、コスト面で）、代わりにクライアント上でわずかに多くの処理能力を要求する。

その場合、Next.js と Vercel のサーバーファースト指向は役に立たず、障害となる可能性があります。

Vike - サーバーとクライアント間の詳細な作業分割

Vike を使えば、前述のユースケースに合わせた設定を選択できます。 SSR を部分的にまたは完全にオプトアウトすることができます（アプリ全体、一部のページ、または 一部のコンポーネント でのオン/オフ）。 また、最初のページに SSR を使用し、そこから先はクライアントのみのナビゲーションを使用しつつ、データソースから直接データを取得する（SSR サーバーを介さない）こともできます。

Vike は、クライアントサイド寄りのサポートはもちろん、SSR のユースケースに対するファーストクラスのサポートを提供します。 Vike はコミュニティによって作られており、クライアントとサーバー間の作業分割のどちらかを優遇するインセンティブはありません。

手動での統合

上述の通り、Vikeの哲学は、フレームワークの決定に縛られることなく、手動でツールを統合できることげある。好きなツールを好きなように使えます。

総合的に見て、Vikeは簡単ではないが、よりシンプルです。大規模なプロジェクトでは、「簡単」であることよりも 「シンプル」であることの方が基本的に重要です。

最後になりますが、フレームワークと戦うのは厄介ですが、手動での統合は楽しく、洞察力に富みます。Vikeは、手動での統合を楽しむことができるフレームワークです。

React Server Components

React 18 は、多くの機能を解き放つ新しい技術を導入しました。

Vike、特に vike-react は、React 18 の新しい技術を広範囲に活用しています。（ストリーミング、プログレッシブレンダリング、独立したデータフェッチングと位置を共有するデータフェッチング、RPC など）

Vike は、React の SSR ストリーム の制御など、適切と思われるツールを統合するための広範な制御を提供します。同時に Vike 拡張機能 は、クイックスタートのための組み込みの統合を提供します。私たちはこの二重のアプローチを オプショナルコントロール と呼んでいます。

vike-react がまだサポートしていない一つの側面は、サーバーサイドでのみロードされるコンポーネントです。私たちはそのようなコンポーネントのための DX を研究していますが、この新しいパラダイムが本番環境で使用されるには時期尚早だと考えています。詳細は インテグレーション > React > React Server Components をご覧ください。

独自のフレームワークを構築

Vikeは、ユーザーがVikeの上にフレームワークを構築できるようにゼロから設計されています。

わずか数百行のコードで、あなた自身のNext.jsを構築することができます。

独自のフレームワークを構築するユースケースはたくさんありますが、最も顕著なのは企業内のフレームワークを構築することです。

私たちは、特定のユースケースに高度に調整されたReactフレームワークの普及を促進しています。

詳細はVike.landへ。