Lors de la création d’applications web, l’une des premières décisions à prendre consiste à choisir entre une “single-page application” (SPA) ou une application multi-pages (MPA). Ce choix a un impact significatif sur le fonctionnement de l’application et les patterns de programmation en jeu, il n’est donc pas facile.
Mais a-t-on vraiment besoin de choisir ? Next.js adopte une approche hybride innovante qui combine les meilleurs aspects des SPA et des MPA.
Clarifions d’abord les principales distinctions techniques entre les SPA et les MPA :
| Aspect | SPA | MPA |
|---|---|---|
| Structure | Un gros fichier index.js | Un fichier .js par page |
| Routage | Routage côté client en JavaScript | Protocole HTTP et hyperliens |
| Avantage | Transitions rapides entre les vues | Bundles plus légers |
| Inconvénient | Chargement initial d’un bundle massif | Rechargement complet de la page lors de la navigation |
Les SPA chargent tout le code JavaScript nécessaire à l’avance et gèrent le routage côté client, permettant des transitions fluides et rapides entre les vues.
Elles fonctionnent un peu comme un logiciel fonctionnant avec un fichier .exe unique : c’est le fichier index.js, la “single page”, qui joue le rôle de l’exécutable. Cette approche a un impact sur le temps de chargement initial de l’application.
Les MPA suivent le modèle traditionnel qui consiste à servir des pages HTML distinctes pour chaque route.
Bien que cela entraîne des rechargements complets de la page lors de la navigation, cela permet d’avoir des bundles JavaScript plus légers car le code est réparti sur plusieurs pages.
En fait, on parle de “MPA” uniquement depuis que les “SPA” existent ! Avant cela, on aurait juste parlé de site web.
Les MPA ont tout de même évolué et se sont améliorées ces dernières années. Des techniques comme le paint holding ont contribué à combler le fossé entre les MPA et les SPA. Le framework Astro, qui a plutôt l’architecture d’une MPA, a introduit un système de “transitions de vues”, désormais appelé routeur client, qui permet aussi d’hybrider les fonctionnalités d’une MPA et d’une SPA.
Next.js adopte une approche hybride, en tirant parti des forces des deux architectures.
Le framework divise l’application en pages individuelles, à l’instar d’une MPA, mais inclut également une couche JavaScript côté client qui permet un comportement similaire à celui d’une SPA.
Par exemple, Next.js pré-rend chaque page sur le serveur pour générer du HTML, un pattern typique d’une MPA. Lorsque la page est chargée dans le navigateur, Next.js hydrate de manière transparente ce HTML statique avec un runtime JavaScript léger, et le routage côté client prend le relais, comme dans une SPA.
L’avantage de cette hybridation est que Next.js découpe automatiquement le code JavaScript en “chunks”, chargeant uniquement ce qui est nécessaire pour chaque page. Et une fois le code JavaScript chargé, le routage client offre une expérience beaucoup plus fluide.
En résumé, les frameworks modernes et Next.js en particulier ont aujourd’hui tendance à ne pas s’enfermer dans un modèle SPA ou MPA, mais plutôt à hybrider intelligemment ces approches pour en tirer le meilleur parti.
Vous avez apprécié cette ressource ?
Découvrez toutes nos formations Next.js et Astro en présentiel ou en distanciel