Next.js vs Remix : valeur sûre ou outil plus affûté ?

Next.js est le choix par défaut pour une raison

Quand les gens disent que Next.js est ennuyeux, ils veulent généralement dire qu'il a gagné.

Le framework a le momentum, le mindshare, les templates, les tutos, le support d'hébergement, la familiarité des outils IA et un gigantesque vivier de développeurs qui l'ont touché au moins une fois. Pour un fondateur, ça compte. Une stack, ce n'est pas juste une décision technique. C'est aussi une décision de recrutement, de support et de capacité à corriger le tir.

Ça ne veut pas dire que Next.js est toujours plus propre. Souvent, il ne l'est pas.

Remix a le cerveau le plus cohérent

Remix tend à plaire aux développeurs qui s'intéressent au web comme un système, pas juste à React comme un modèle de composants. Loaders, actions, routes imbriquées, soumissions de formulaires, progressive enhancement et cycles de vie de requêtes -- tout s'emboîte d'une manière qui paraît intentionnelle.

Cette cohérence est rare. C'est une des raisons pour lesquelles Remix a des fans aussi loyaux.

Le problème, ce n'est pas le framework en soi. C'est l'écosystème autour. Quand on a besoin d'une librairie, d'un starter, d'un hébergeur ou d'une recette de prod obscure, l'internet parle Next.js beaucoup plus fort.

Les features en résumé

Next.js en 2026 est un gros framework. L'App Router a apporté les Server Components, les Server Actions, les layouts imbriqués, le streaming, le Middleware pour la logique edge, et l'ISR (Incremental Static Regeneration) pour les pages qui se reconstruisent sur un timer sans redéploiement complet. On peut mixer pages statiques, pages server-rendered et routes full dynamiques dans le même projet. La flexibilité est réelle, mais la surface à comprendre aussi.

Remix donne des loaders (data fetching server-side par route), des actions (handlers de mutation server-side par route), des routes imbriquées avec leur propre ErrorBoundary, et du progressive enhancement qui fait que les formulaires marchent même avant que le JavaScript charge. La liste de features est plus courte volontairement. Remix choisit une voie et y reste.

La fusion avec React Router

C'est un contexte important. Remix a fusionné avec React Router à partir de la v7. Si on utilise React Router v7 aujourd'hui, on utilise essentiellement l'architecture de Remix. L'équipe Remix a intégré ses patterns (loaders, actions, routes imbriquées) directement dans le router.

En pratique : Remix comme marque standalone s'efface, mais ses idées deviennent la façon par défaut dont React Router fonctionne. Si on démarre un nouveau projet React Router v7 avec du server-side rendering, on récupère le modèle mental de Remix qu'on l'appelle comme ça ou non.

Pour l'écosystème, c'est à la fois positif et confus. Positif parce que les patterns de Remix touchent plus de développeurs. Confus parce que "est-ce que je dois utiliser Remix ou React Router ?" est maintenant une question floue dont la réponse est "c'est la même chose."

Philosophie du data loading

C'est là que les deux frameworks se sentent le plus différents au quotidien.

Next.js permet de fetcher des données dans les composants via des Server Components async. On peut fetcher au niveau du layout, de la page ou en profondeur dans un arbre de composants. Le comportement de cache dépend de la configuration et des options cache de l'API fetch. C'est flexible, mais cette flexibilité veut dire qu'il faut réfléchir à où le data fetching se passe, comment ça cache et quand ça revalide. Le modèle mental a beaucoup de boutons.

Remix prend une position différente. Chaque route a une fonction loader qui tourne sur le serveur avant que le composant rende. Les données passent du loader au composant via useLoaderData(). Routes imbriquées signifie loaders imbriqués, et ils tournent tous en parallèle. Pas d'ambiguïté sur d'où viennent les données ou quand elles tournent. La frontière serveur est explicite.

Pour les apps avec des dépendances de données complexes, le modèle de Remix tend à produire moins de surprises. On sait exactement ce qui tourne où. Dans Next.js, mixer Server Components, composants client et différentes stratégies de cache peut créer un comportement difficile à raisonner tant qu'on n'a pas vraiment intériorisé le modèle.

Gestion des formulaires et mutations

Remix a été construit autour des formulaires. De vrais formulaires HTML. Le composant <Form> envoie vers une fonction action sur la même route, qui gère la mutation côté serveur et revalide les données du loader automatiquement. C'est du progressive enhancement par défaut : si le JavaScript plante, le formulaire marche quand même parce que c'est une vraie soumission de formulaire.

Next.js a ajouté les Server Actions pour gérer les mutations. On écrit une fonction avec "use server" en haut, et elle peut être appelée depuis un composant client ou une form action. Ça marche bien et la DX s'est beaucoup améliorée, mais c'est un pattern plus récent et l'écosystème rattrape encore. Les Server Actions ressemblent plus à des appels RPC ; les actions de Remix ressemblent plus à du form handling web-natif.

Si l'app est form-heavy (panneaux admin, dashboards, apps CRUD), l'approche Remix tend à paraître plus naturelle. Si l'app est plus interactive avec moins de soumissions de formulaires traditionnelles, la différence compte moins.

Hébergement et déploiement

Next.js est optimisé pour Vercel. Ce n'est pas un secret. Vercel construit Next.js, et leur plateforme supporte chaque feature Next.js dès le premier jour. Mais Next.js tourne aussi sur Netlify, Railway, Fly.io, AWS via SST ou OpenNext, des containers Docker, et partout où on peut faire tourner un serveur Node.js. Le hic, c'est que certaines features (ISR, Middleware, optimisation d'images) marchent le mieux sur Vercel, et le self-hosting demande de configurer des choses que Vercel gère automatiquement.

Remix tourne partout où il y a du support Node.js ou Deno. Il a été construit avec un déploiement par adaptateurs : on choisit un adaptateur pour sa cible (Express, Cloudflare Workers, Vercel, Netlify, Fly.io, Deno Deploy) et on déploie. Pas d'hôte "béni" unique. Remix se sent plus portable, mais ça signifie aussi qu'aucun hébergeur ne fait de travail supplémentaire pour faire briller les features Remix.

En pratique, les deux frameworks se déploient bien sur la plupart des plateformes modernes. Mais si on veut l'expérience de déploiement la plus simple possible, Next.js sur Vercel est difficile à battre. Si on veut éviter le lock-in plateforme, Remix donne moins de soucis.

Taille de la communauté et écosystème

Il n'y a pas photo. Next.js a environ 10x les téléchargements npm hebdomadaires de Remix. Plus de templates, plus de tutos, plus d'articles de blog, plus de réponses Stack Overflow, plus d'intégrations tierces, plus de starter kits. Si on cherche "comment faire X avec Next.js", on trouve une réponse. Avec Remix, on en trouvera peut-être une, ou il faudra comprendre à partir de la doc.

Pour un fondateur, la taille de l'écosystème se traduit directement en vitesse de développement. On passe moins de temps à résoudre des problèmes que quelqu'un d'autre a déjà résolus et documentés.

Le backing corporate

Vercel soutient Next.js. Shopify soutient Remix (via la fusion React Router, puisque Shopify a racheté Remix). Les deux frameworks ont de vrais sponsors corporate avec du vrai argent derrière.

La différence, c'est que le business model de Vercel est directement lié à l'adoption de Next.js. Plus d'utilisateurs Next.js signifie plus de clients Vercel. Ça crée une forte incitation à continuer d'investir dans le framework, mais ça veut aussi dire que certaines features sont conçues avec le déploiement Vercel en tête.

Shopify utilise Remix/React Router pour Hydrogen, leur framework commerce headless. L'investissement est réel, mais le lien entre le revenu de Shopify et l'adoption de Remix est moins direct.

Aucun des deux frameworks ne va disparaître. Les deux ont de la tenue.

Quand choisir Next.js

• On veut le pari marché le plus sûr pour un produit basé sur React.
• On s'attend à recruter ou transmettre le projet et on veut le plus gros vivier de talents.
• On a besoin d'un framework qui gère pages marketing, surfaces app et contenu dans le même projet.
• On veut l'écosystème le plus riche en templates, plugins et solutions communautaires.
• On est ok avec Vercel ou prêt à faire le travail supplémentaire pour du self-hosting.
• Les outils de code IA connaissent déjà Next.js par coeur.

Quand choisir Remix

• On s'intéresse aux fondamentaux web et on veut un framework qui respecte le fonctionnement réel du web.
• On préfère un data loading explicite avec des frontières serveur claires plutôt qu'un caching flexible mais complexe.
• On construit une app form-heavy et on veut du progressive enhancement par défaut.
• On veut déployer partout sans se soucier de features spécifiques à une plateforme.
• On veut un framework qui dit "fais-le comme ça" plus souvent et qui laisse moins de décisions architecturales.
• On sait déjà qu'on aime le pattern loader/action de React Router v7.

Verdict

Next.js reste le choix par défaut qu'on recommanderait à la plupart des fondateurs. L'avantage écosystème seul vaut beaucoup quand on essaie d'avancer vite et qu'on ne peut pas se permettre de rester bloqué sur un problème dont personne n'a écrit la solution.

Remix est l'outil plus affûté pour un certain type d'équipe. Si on valorise le flux de données propre, les patterns web-natifs et la discipline architecturale plus que la taille de l'écosystème, Remix récompensera. La fusion React Router v7 signifie aussi que même si "Remix" comme marque s'efface, les idées gagnent.

Si on sent l'attraction vers Remix, c'est en général un vrai signal sur la façon dont on pense la construction. Si on cherche juste le chemin le plus sûr pour passer à autre chose, on choisit Next.js et on expédie.