Next.js est en train de mourir. Découvrez Vike.

Les développeurs React continuent de décrire la même sensation troublante : leur application Next.js semble lente même avant de devenir importante. Vous cliquez sur un lien en localhost et attendez 1 à 2 secondes que le serveur de développement réponde, le remplacement à chaud des modules hésite, et chaque modification donne l'impression de pousser du code à travers de la mélasse plutôt que de progresser en temps réel.

Ce ralentissement n'est pas seulement une question de perception ; il provient du poids et de l'ambition du framework. Next.js tente d'être à la fois votre routeur, votre empaqueteur, votre temps d'exécution serveur, votre couche de données et votre histoire de déploiement, le tout à la fois, et chaque couche de "commodité" se trouve entre vous et le navigateur, ajoutant une surcharge tant aux temps de construction qu'aux boucles de rétroaction.

Le design tout-en-un intègre également une méthode très spécifique pour créer des applications React. Le routage par le système de fichiers, les routes API, les composants serveur, les conventions de router d'application et les paramètres de déploiement centrés sur Vercel forment un ensemble cohérent d’hypothèses qui fonctionnent brillamment pour un blog ou une page d'atterrissage, mais qui commencent à être contraignantes lorsque vous avez besoin de flux de données non conventionnels ou d'infrastructures personnalisées.

Une fois que vous adoptez ces opinions, faire marche arrière devient coûteux. Vous voulez changer de routage, expérimenter une stratégie de rendu différente ou introduire progressivement une autre pile UI ? Avec Next.js, vous êtes souvent confronté à des réécritures complètes, des solutions instables ou un enchevêtrement de configurations qui résistent encore aux paramètres par défaut du framework.

Les développeurs découvrent cela comme un compromis explosif. Vous avancez rapidement pour le MVP, mais à mesure que l'application se transforme en tableau de bord multi-locataire ou en SaaS complexe, les mêmes abstractions qui semblaient magiques deviennent des freins : des builds plus lents, des bundles plus volumineux et des schémas qui résistent au refactoring.

Cette friction se manifeste également dans le code expédié. Les bundles clients typiques de Next.js pour des pages non triviales atteignent facilement la plage de 70 à 100 kB avant d'ajouter des bibliothèques d'interface utilisateur sérieuses, tandis que les configurations plus légères restent régulièrement dans la plage de 10 à 15 kB, ce qui affecte directement les temps de chargement, le temps jusqu'à l'interaction et les scores Lighthouse.

L'expérience des développeurs en prend un coup avec la performance. Des temps de démarrage longs sur le développement, des erreurs opaques profondes dans la pile de frameworks, et le bouleversement causé par des changements majeurs de fonctionnalités comme les composants serveur React s'additionnent pour créer une impression que le framework, et non votre produit, domine votre journée.

C'est pourquoi une nouvelle génération d'outils, dont Vike basé sur Vite, cible explicitement cette lourdeur, promettant des paquets plus légers, des retours plus rapides et moins de dépendance sans vous obliger à abandonner l'écosystème React.

Rencontrez Vike, un méta-framework modulaire basé sur Vite et visant explicitement l'espace que Next.js a créé. Au lieu d'un monolithe dictant le routage, la récupération de données et le déploiement, Vike se concentre sur une seule tâche : intégrer le SSR, le SSG et le routage au serveur de développement et au bundler ultra-rapides de Vite.

Né en 2021 sous le nom de `vite-plugin-ssr`, Vike a discrètement évolué dans l'ombre pendant que les développeurs React débattaient sur les routeurs d'application et les composants serveur. Un rebranding en 2023 lui a donné une identité plus claire, et depuis, il a franchi les 5 000 étoiles sur GitHub, signalant que ce n'est plus une expérience de week-end mais un framework avec une réelle attraction.

La philosophie fondamentale de Vike semble presque réactionnaire en 2025 : être non-opinionné, rester sous licence MIT et éviter les réécritures alimentées par le battage médiatique. Les mainteneurs la présentent comme étant « ennuyeuse de manière positive » — un outil qui évolue lentement, privilégie la configuration explicite et vous permet d'apporter votre propre pile pour les données, l'authentification et l'état au lieu de vous contraindre à un chemin prédéfini.

Là où Next.js s'appuie fortement sur des conventions imposées — `app/` contre `pages/`, routes basées sur des fichiers, actions serveur, composants serveur React — Vike réduit les choses à des éléments fondamentaux. Vous définissez vous-même les routes, les configurations des pages et les modes de rendu, puis vous optez pour des fonctionnalités comme le SSR, le SSG ou le rendu uniquement côté client au cas par cas avec de simples booléens et fichiers de configuration.

Ce modèle minimal et basé sur l'opt-in s'étend à la couche UI. Vike se moque que vous utilisiez React, Vue ou Solid ; le même projet peut les mélanger comme des « îlots » sur une seule page sans adaptateurs ni wrappers. Vous obtenez des hooks de bas niveau et des éléments de construction, pas un framework qui exige que chaque composant utilise les React Server Components ou vive dans un arbre de répertoires prescrit.

Les développeurs frustrés par les fréquents changements disruptifs de Next.js et son alignement systématique avec un fournisseur d'hébergement voient la retenue de Vike comme une caractéristique, et non un défaut. Pas d'optimiseur d'images intégré, pas de couche de données magique, pas de routes API propriétaires — juste Vite, le routage et des primitives SSR qui se mettent en retrait pendant que vous assemblez le reste de la pile vous-même.

Les puristes de React pourraient vouloir détourner le regard, car le trick le plus subversif de Vite est qu'il ne se soucie plus du framework UI que vous utilisez. Son routage, le chargement des données et son pipeline de rendu se situent en dessous de la couche des composants, permettant ainsi à l'interface utilisateur de devenir un ensemble d'« îlots » pouvant provenir de React, Vue, Solid ou de tout autre framework que Vite peut compiler.

Dans la démo de Better Stack, la page À propos fonctionne comme une route React standard, mais la section des compétences au milieu de cette page est un composant Vue. Pas d’iframe, pas de micro-frontend shell, pas de couche d’adaptateur personnalisée—juste une île Vue montée directement dans une page React avec aucun wrapper, aucun hack.

Ce modèle d'île semble académique jusqu'à ce que l'on pense aux micro-frontends. Vike permet aux équipes de diviser une application en segments implémentés de manière indépendante, de sorte qu'une équipe puisse livrer un tableau de bord Vue, une autre puisse maintenir un processus de paiement React hérité, et une troisième puisse expérimenter avec Solid pour un widget à forte interaction, le tout au sein d'un même espace URL.

Les plateformes multi-locataires en bénéficient encore davantage. Un SaaS qui propose des tableaux de bord en marque blanche pour des dizaines de clients peut héberger : - Des outils administratifs basés sur React - Des analyses axées sur Vue pour un client spécifique - Des widgets en temps réel basés sur Solid

Tout sous une seule application Vike, sans déployer des infrastructures séparées ni forcer chaque client à utiliser la même pile.

Les migrations progressives semblent enfin raisonnables ici. Au lieu d'une réécriture brutale en mode big-bang, une équipe peut remplacer une page React Next.js morceau par morceau : réimplémenter une seule section en tant qu'île Vue ou Solid, la valider en production, puis élargir le rayon d'effet. Les hooks de bas niveau de Vike maintiennent la cohérence du SSR, de l'hydratation et du routage pendant que la couche UI évolue.

Next.js ne facilite tout simplement pas les choses. Son modèle mental entier, allant du routage basé sur le système de fichiers à la récupération de données et aux composants serveur React, suppose React partout, tout le temps. Mélanger Vue ou Solid dans une structure Next.js signifie généralement des hacks fragiles avec webpack, des builds séparés, ou des micro-frontends complets avec tout le surcoût opérationnel que cela implique.

Vike, en revanche, s'appuie sur l'écosystème de Vite et considère les frameworks comme des plugins plutôt que comme une religion. La page GitHub du projet, [vikejs/vike : [alternative à Next.js/Nuxt] Le composable ... - GitHub](https://github.com/vikejs/vike), fait explicitement la promotion d'îles indépendantes de tout framework et d'une "flexibilité sans précédent" comme objectifs majeurs.

Pour les équipes confrontées à une migration sur plusieurs années, à une acquisition complexe ou à un portefeuille d'interfaces dépareillées, cette flexibilité n'est pas un simple tour de magie. C'est une manière de continuer à produire pendant que votre pile technologique se met à jour avec la réalité.

La taille du bundle raconte l'histoire. Dans la démo de Better Stack, les pages Vike expédient régulièrement des bundles clients dans la plage de 10–15 kB, tandis que les pages Next.js comparables gonflent à 70–100 kB+ avant même d'ajouter du vrai code d'application. Cette différence de 5 à 10 fois n'est pas une erreur d'arrondi ; elle modifie la rapidité avec laquelle votre interface utilisateur s'affiche et réagit.

Vike réussit cela en utilisant directement Vite au lieu de superposer son propre système de construction. Les modules ES natifs de Vite, le pré-empaquetage et le serveur de développement signifient que le remplacement à chaud des modules semble presque instantané, pas « attendez deux secondes et espérez ». Vous voyez les modifications reflétées en un clin d'œil, même à mesure que votre projet dépasse le stade de jouet.

Next.js, en revanche, entraîne un runtime plus lourd, plus d'abstractions et beaucoup de JavaScript client par défaut dans chaque route. Vous payez pour le routage, les hooks de données et le câblage des composants serveur React, que vous les utilisiez ou non. Cette taxe de base est la raison pour laquelle une application Next « hello world » pèse déjà des dizaines de kilooctets dans le navigateur.

Des paquets plus petits signifient moins de JavaScript à télécharger, analyser et exécuter, ce qui réduit directement le Temps jusqu'au Premier Octet (TTFB) et le Temps jusqu'à l'Interaction. Un paquet de 15 kB arrive souvent en un seul aller-retour réseau, surtout sur HTTP/2, et s'analyse en quelques millisecondes sur des téléphones de milieu de gamme. Un paquet de plus de 100 kB doit lutter contre la bande passante, la latence et des processeurs plus lents avant que les utilisateurs puissent toucher quoi que ce soit.

Le design de Vike garde la charge du navigateur concentrée sur votre interface utilisateur, et non sur les rouages du framework. Vous ne déployez que les îlots et les composants qui fonctionnent réellement sur le client, plutôt qu'un shell d'application monolithique. Pas de routeur client automatique si vous n'en avez pas besoin, pas de logique d'hydratation pour les pages qui s'affichent correctement en HTML statique.

Cette philosophie rend également les performances plus prévisibles. Lorsque vous ajoutez une nouvelle fonctionnalité, vous pouvez voir exactement quels modules affectent le bundle client et dans quelle mesure, grâce à la sortie de construction transparente de Vite. L’optimisation des performances consiste à affiner les dépendances réelles, plutôt qu'à fouiller dans les internes du framework que vous n’avez jamais demandés.

Next.js vous demande d'adopter sa vision du monde. Vous obtenez des conventions comme `getServerSideProps` et `getStaticProps`, un routage automatique, et des composants serveur React intégrés, mais vous héritez également d'un lot de comportements invisibles : quand les données se chargent, comment elles sont mises en cache, où le code s'exécute. Une fois que votre application ne ressemble plus à un blog, cette "magie" devient quelque chose que vous devez déboguer plutôt que d'en tirer parti.

Vike va dans l'autre sens et vous remet le câblage. Le mode de rendu devient un indicateur de configuration explicite sur chaque page (`ssr: true` ou `false`), vous décidez donc quelles routes sont pré-rendues, lesquelles se réhydratent et lesquelles restent seulement côté serveur. Pas de cascades cachées, pas de cadre devinant votre intention à partir d'un nom de fichier.

La récupération de données dans Vike ressemble davantage à du TypeScript classique qu'à un rituel de framework. Au lieu de fonctions de cycle de vie spéciales, vous utilisez des hooks bas niveau et un modèle appelé Telefunc pour définir des fonctions serveur dans des fichiers `.ts` et les appeler directement depuis le client. Vike gère la sérialisation et le routage en arrière-plan, mais vous laisse entièrement le contrôle sur quand et comment vous récupérez les données.

Telefunc remplace essentiellement les routes API pour la plupart des cas d'utilisation. Vous écrivez quelque chose comme `addEntry()` dans un fichier Telefunc, importez un client généré sur le frontend, et appelez `await addEntry(...)` avec une typage complet de bout en bout. Pas de `pages/api`, pas de code de base REST, pas de couche GraphQL supplémentaire à moins que vous ne le souhaitiez.

Parce que Telefunc expose simplement des fonctions, il s'intègre parfaitement avec les outils existants. Vous pouvez envelopper les entrées dans des schémas Zod pour la validation à l'exécution, puis en déduire des types TypeScript à partir de ces schémas sans frais. Cela vous offre une source unique de vérité pour les contrats de données au lieu de jongler avec des DTOs, des gestionnaires d'API et des types clients.

Vike reste également en dehors de votre stratégie de mise en cache. Vous souhaitez associer Telefunc avec TanStack Query ? Vous placez vos appels Telefunc à l'intérieur de `useQuery` ou `useMutation`, configurez les durées de péremption et les réessais, et vous avez une couche de données entièrement personnalisée qui reste conforme à l'idiome de React. Pas besoin de lutter contre un cache au niveau du cadre qui insiste pour revalider ou refetcher à des moments inappropriés.

Les équipes expérimentées ont tendance à apprécier ce genre de clarté. Si vous savez déjà comment vous souhaitez gérer l'authentification, le traitement des erreurs et la normalisation des données, la pile tout-en-un de Next.js peut donner l'impression de garde-fous soudés au châssis. L'approche de Vike implique plus de décisions dès le départ, mais vous êtes responsable de chacune d'elles.

Cette propriété est importante lorsque votre application dépasse le méta actuel. Avec Vike, votre architecture est simplement TypeScript, Vite, et les bibliothèques que vous avez choisies, et non une boîte noire qui pourrait changer son modèle de données l'année prochaine. Pour les équipes ayant souffert de changements brusques et de comportements cachés, "votre application, vos règles" n'est pas un slogan ; c'est de la gestion des risques.

Photon est la partie de Vike qui répond discrètement à la question la plus difficile des frameworks web modernes : où cette chose s'exécute-t-elle réellement ? Présenté comme un outil de déploiement plutôt que comme un autre runtime, Photon emballe votre application Vike afin qu'elle s'installe facilement sur des plateformes de périphérie comme Cloudflare Workers et Vercel, sans un rituel DevOps sur mesure pour chaque cible.

Au lieu d'expédier un serveur Node volumineux, Photon compile vos routes en petites fonctions adaptées aux bords. Cela s'inscrit parfaitement dans l'histoire de Vike de « petits paquets, petite surface d'attaque » : un JavaScript minimal côté client, un surcharge minimale côté serveur, et aucun processus monolithique inactif dans une région que vous n'avez pas choisie.

Le résultat est exactement ce que les fournisseurs de solutions en edge promettent depuis des années : pas de démarrages à froid et un TTFB très bas. Les travailleurs s'initient près des utilisateurs, Vike diffuse le HTML rapidement, et vous évitez la pénalité de 300 à 800 ms qui accompagne le démarrage d'un serveur Node traditionnel, en particulier sur des itinéraires à faible trafic ou des configurations multi-régionales.

Photon s'efforce également de normaliser le chaos des plateformes de edge. Au lieu d'apprendre les particularités de Cloudflare, les règles de runtime edge de Vercel et les pièges des systèmes de fichiers de chaque fournisseur, vous configurez Vike une fois et laissez Photon émettre les bons artefacts et adaptateurs selon la cible.

Cela positionne Vike résolument dans le camp des approches orientées vers le rendu à la demande aux côtés de Remix et SvelteKit, qui s'appuient déjà sur des environnements d'exécution distribués pour plus de rapidité. La différence est philosophique : Vike reste plus proche de Vite et des primitives SSR classiques, tandis que Photon gère la traduction finale vers des environnements de type Workers.

Le déploiement en périphérie devient rapidement une exigence incontournable pour les frameworks de l'ère React. Des guides comme Top 5 alternatives à Next.js pour les développeurs React - Blog LogRocket considèrent de plus en plus « fonctionner à la périphérie » comme une case à cocher, et non comme un bonus. Photon est la réponse de Vike à cette attente.

Pour les équipes coincées entre les hypothèses orientées Vercel de Next.js et les configurations DIY SSR avec Vite, Photon transforme Vike en une option crédible, prête pour la production, qui trouve réellement sa place sur l’ensemble du réseau mondial.

Le principal atout de Vike—le contrôle—devient également son aspect le plus tranchant. Vous ne bénéficiez pas du confort « batteries comprises » qui a fait de Next.js la réponse par défaut de React pour les startups et les agences. Vike vous fournit des primitives et s'attend à ce que vous assembliez un cadre, pas seulement un projet.

D’entrée de jeu, vous ne trouverez pas le mélange de commodités que les développeurs Next.js considèrent comme acquis. Pas de pipeline d'optimisation d'image intégré, pas de solution d'authentification de première partie, pas de couche de routes API opinionnée, et pas d'analytique, de polices ou de piles de middleware officielles. Vous devez configurer des fonctionnalités comme les téléchargements de fichiers, la limitation du taux et le caching vous-même, généralement en choisissant des bibliothèques tierces.

Cette modularité semble puissante seulement si vous savez déjà quels éléments vous souhaitez. Pour de nombreuses équipes, l'écosystème de préréglages manquant nuit plus que les gains de performance brute n'apportent d'aide. Vous échangez l'expérience "ajoutez un plugin et ça marche" de Next.js contre la lecture de la documentation et l'assemblage d'outils comme TanStack Query, Zod et vos propres conventions de routage.

Next.js surpasse également Vike en termes de poids communautaire. Next dispose de milliers de tutoriels, de réponses sur Stack Overflow et d'études de cas en production ; Vike n'a qu'une poignée d'articles de blog, un Discord plus restreint et quelques exemples éparpillés sur GitHub. Lorsque vous rencontrez un cas particulier étrange de SSR ou un quirk de déploiement, vous êtes moins susceptible de coller une erreur dans une barre de recherche et de trouver une solution à copier-coller.

Cette plus petite écosystème se traduit par moins d'intégrations abouties. Vous ne verrez pas un marché d'adaptateurs officiels pour chaque CMS sans tête, fournisseur d'authentification et passerelle de paiement. Au lieu de cela, vous connectez manuellement des services comme Auth0, Clerk ou Stripe, décidant comment les jetons circulent à travers les fonctions serveur et comment hydrater l'état sur le client.

Les équipes orientées vers React font face à un autre défi : les composants serveur React ne sont pas encore complètement opérationnels. Vike peut approcher le modèle avec des fonctions serveur et une hydratation selective, mais vous ne bénéficiez pas de l'histoire fluide des RSC sur laquelle s'appuie Next.js 13+. Si vous êtes déjà engagé dans des modèles RSC, des mises en page et du streaming, Vike semble actuellement être un pas sur le côté, et non en avant.

Vike minimaliste vous donne un sentiment d'autonomisation jusqu'à ce que vous réalisiez que vous possédez désormais tout. Cette liberté de choisir votre routeur, votre couche de données, votre stratégie de mise en cache et votre pile d'authentification signifie également un coût initial de configuration plus élevé et une facture de maintenance continue qui était autrefois le problème de Next.js, pas le vôtre.

Les développeurs qui utilisent `create-next-app` reçoivent une rude surprise lorsque un projet Vike commence comme peu plus qu'un routage, des primitives SSR/SSG et quelques fichiers de configuration. Vous choisissez comment structurer les pages, où placer les appels API et comment gérer l'invalidation du cache, ce qui ralentit les projets en phase de démarrage qui ont simplement besoin d'être livrés.

La vidéo qualifie la courbe d'apprentissage de « plutôt drôle » précisément parce que Vike refuse de cacher la complexité. Vous configurez la récupération et le caching des données vous-même avec des hooks, au lieu de laisser la logique dans `getServerSideProps` ou `getStaticProps` et de laisser le framework orchestrer le tout.

La documentation amplifie la douleur une fois que vous quittez le chemin heureux. Les concepts de base du SSR et du routage semblent suffisamment clairs, mais les configurations avancées de React, les îles de frameworks mixtes et les modèles spécifiques aux edge ont encore des documents fragmentaires, obligeant les développeurs à rétroconcevoir des exemples ou à explorer les problèmes sur GitHub.

Cette flexibilité autour des données montre les deux faces de la pièce. Vous voulez TanStack Query, des wrappers de récupération personnalisés ou une couche RPC développée en interne ? Vike se tient à l’écart, mais refuse également de vous fournir une solution standardisée, prête à l'emploi, sur laquelle une équipe puisse se baser par défaut.

Chaque projet sérieux finit par assembler sa propre pile pour :

• 1Récupération et mise en cache des données
• 2Authentification et sessions
• 3Optimisation des images et gestion des ressources
• 4Limites d'erreur et observabilité

La propriété signifie également posséder les arêtes vives. La vidéo mentionne des décalages d'hydratation récurrents dans les applications à forte composante React et des particularités de TypeScript que l'on ne voit jamais dans Next.js, car le framework de Vercel a passé des années à les lisser.

Les équipes qui migrent des rails soignés de Next.js vers la boîte à outils ouverte de Vike ressentent le plus cette friction. Vous échangez des garde-fous et une expérience développeur intégrée contre un contrôle brut, et les premières semaines peuvent ressembler moins à un gain de productivité qu'à une ingénierie de framework sans gant.

Choisir entre Vike et Next.js commence par une question claire : optimisez-vous pour les trois prochains mois ou pour les trois prochaines années ? Des délais courts et des exigences floues privilégient la convention et les fonctionnalités incluses. Les systèmes durables avec des contraintes évolutives récompensent le contrôle explicite et la composabilité.

Vike brille lorsque l'architecture compte plus que la rapidité de l'échafaudage. Les équipes planifiant des plateformes pluriannuelles, des SaaS multi-locataires ou des configurations de micro-frontend tirent parti de ses îlots indépendants du framework, de ses petits bundles de 10 à 15 kB, et de ses commutateurs SSR/SSG par page. Vous échangez une ergonomie instantanée contre un système qui se plie plutôt que de se briser lorsque les exigences évoluent.

Les micro-frontends et les réécritures progressives sont là où Vike se sent désavantagé. Vous devez exécuter React pour votre tableau de bord, Vue pour un ancien admin, et Solid pour une nouvelle expérience marketing sur le même domaine ou même la même page ? Les hooks de bas niveau et la couche de routage de Vike vous permettent de rassembler tout cela sans les contraintes du « un seul framework pour les gouverner tous » qui rendent des mouvements similaires dans Next.js douloureux.

Les équipes obsédées par la performance ont également de solides arguments en faveur de Vike. Si vos budgets exigent des charges utiles initiales inférieures à 20 kB, le rendu en périphérie via Photon sur Cloudflare Workers ou Vercel, et un surcoût d'hydratation minimal, le cœur léger de Vike et le HMR propulsé par Vite vous offrent plus de marge de manœuvre qu'un paquet Next.js typique de 70 à 100 kB. Vous maîtrisez les compromis au lieu de les hériter.

Next.js reste le choix gagnant lorsque vous devez expédier hier. Pour des MVP rapides, des sites marketing riches en contenu, et des tableaux de bord qui s'appuient sur Markdown, les intégrations CMS et l'optimisation des images, ses fonctionnalités intégrées réduisent la fatigue de décision. Vous bénéficiez de routage basé sur des fichiers, de routes API, de gestion d'images et de composants serveur React sans avoir à assembler une pile de zéro.

Les équipes fortement investies dans l'écosystème Vercel devraient réfléchir à deux fois avant de faire le saut. Si vos flux de travail dépendent déjà des aperçus Vercel, des analyses, des fonctions edge et de l'écosystème plus large des plugins Next.js, rester sur place simplifie votre outil et votre histoire de recrutement. Passer à Vike uniquement pour reconstruire ce que Next.js vous offre en standard n'a guère de sens.

En fin de compte, le choix repose sur trois variables : l'expertise de l'équipe, l'horizon du projet et l'appétit pour la prise de contrôle. Les équipes composées principalement de seniors, qui construisent des systèmes critiques à long terme, peuvent justifier les frictions initiales de Vike. Les équipes plus petites, les sites de contenu et les MVP éphémères tirent encore plus de levier de Next.js.

Les frameworks modulaires comme Vike ne sont pas un chemin insolite ; ils représentent l'étape logique après une décennie d'outils React monolithiques. À mesure que les applications ont évolué, le modèle du « un framework pour les gouverner tous » a commencé à se fissurer sous le poids de la complexité du monde réel, des budgets de performance et des bases de code pérennes.

L'essor de Vike, Astro et TanStack Start indique une demande claire : les développeurs veulent des primitives composables, pas des religions regroupées. Ces outils privilégient des noyaux réduits, des fonctionnalités en option et un câblage explicite plutôt que des dossiers magiques et des conventions globales.

Astro a popularisé l'idée des îles et des pages sans JS par défaut. TanStack Start s'articule autour du contrôle de la couche de données et des primitives de routage plutôt que d'un runtime tout-en-un. Vike va encore plus loin en permettant à React, Vue et Solid de coexister dans une même application, sur une seule page, sans adaptateurs ni astuces.

Cette modularité ouvre la voie à des gains pratiques. Vous pouvez migrer une section React héritée vers Vue de manière incrémentale, expérimenter avec Solid dans une île unique, ou exécuter des frontends multi-tenant qui personnalisent les stacks par client sans réécrire la plateforme.

Le contrôle ne signifie pas faire marche arrière sur les capacités. Vike vous offre toujours un SSR et un SSG modernes, ainsi qu'un déploiement en périphérie via Photon, en plus de packages clients qui se situent souvent dans la plage de 10 à 15 kB, au lieu des 70 à 100 kB que vous voyez dans de nombreuses constructions Next.js. Vous décidez par page s'il s'agit de SSR, SSG ou entièrement côté client.

La stabilité fait partie de l'argument. Le "noyau" apparemment "ennuyeux" de Vike, sous licence MIT, ne cherche pas à suivre les composants serveur de React tous les six mois, ce qui est important si vous prévoyez de maintenir un produit en vie pendant cinq ou dix ans plutôt qu'un simple cycle de financement.

Si Next.js semble vous résister, suivez les conseils de la vidéo : lancez un projet secondaire avec Vike. Connectez quelques pages, déployez avec Photon, ajoutez une ou deux îles, et voyez si un avenir modulaire se révèle plus agréable entre vos mains.

Qu'est-ce que Vike et en quoi est-il différent de Next.js ?

Vike est un métafabricant modulaire basé sur Vite qui offre des capacités fondamentales de SSR/SSG sans la structure unifiée et opinionnée de Next.js. Il privilégie la flexibilité, le contrôle et la performance, permettant aux développeurs de choisir leurs propres outils et architecture.

Puis-je utiliser React, Vue et Solid dans le même projet Vike ?

Oui. L'une des principales caractéristiques de Vike est sa couche d'interface utilisateur indépendante du framework. Vous pouvez utiliser React, Vue, Solid et d'autres frameworks ensemble dans la même application, même sur la même page, en utilisant une architecture en 'îlots' sans wrappers spéciaux.

Vike est-il prêt pour la production en 2025 ?

Vike est considéré comme stable et est utilisé en production par diverses entreprises. Cependant, son écosystème est plus petit que celui de Next.js, ce qui signifie que vous devrez assembler davantage de composants comme l'authentification et l'optimisation des images vous-même. Il est mieux adapté aux équipes expérimentées qui apprécient le contrôle et la stabilité à long terme.

Quels sont les principaux inconvénients de l'utilisation de Vike ?

Les principaux inconvénients incluent un écosystème plus restreint, moins de fonctionnalités intégrées (ce n'est pas du 'tout-en-un') et une courbe d'apprentissage initiale plus escarpée, car vous devez vous charger vous-même de la récupération des données et d'autres logiques. La documentation peut également être moins complète que celle de Next.js pour des cas d'utilisation avancés.