- Avec l’arrivée de fonctionnalités CSS modernes comme la View Transitions API, il n’est désormais plus nécessaire d’adopter une architecture SPA pour obtenir des transitions de page fluides
- La plupart des sites en SPA n’offrent en réalité ni les performances ni la fluidité d’expérience promises, et leur JavaScript lourd tend au contraire à dégrader l’expérience utilisateur
- Dans les navigateurs basés sur Chromium, l’usage des transitions de page natives et des Speculation Rules permet de mettre en place une navigation rapide et naturelle sans JavaScript
- La complexité structurelle des SPA nuit aux optimisations du navigateur ; pour un vrai site web, une architecture MPA centrée sur HTML et CSS est plus rapide et plus simple à maintenir
- À l’avenir, il faudra éviter d’adopter des SPA sans nécessité et s’appuyer sur le CSS moderne et les fonctionnalités natives pour développer des sites web efficaces et faciles à maintenir
Introduction : la fin des SPA et l’émergence du CSS moderne
- Avec l’arrivée récente de fonctionnalités CSS modernes comme la View Transitions API, les principaux avantages autrefois apportés par les SPA (single-page applications) ne sont désormais plus nécessaires
- De nombreuses équipes de développement choisissent encore des frameworks SPA comme React ou Vue, mais cette décision repose moins sur la performance que sur une idée fausse autour des interactions et de la fluidité de navigation
- Croire qu’un SPA est indispensable pour offrir une navigation fluide relève déjà d’une vision dépassée
L’illusion des SPA face à la réalité
- Les SPA ont longtemps été la seule façon de proposer des transitions de page naturelles, mais ce n’est plus le cas aujourd’hui
- Beaucoup de SPA présentent les problèmes suivants :
- seulement des effets de fondu sur les états de chargement, sans véritable fluidité dans les transitions de contenu
- des problèmes de restauration du scroll et une gestion incohérente du focus
- des retards de navigation dus au rendu et à l’hydratation
- des layout shifts, des apparitions soudaines de contenu et du skeleton loading
- une complexité inutile et un usage excessif de JavaScript pour un bénéfice limité en matière de performances
- Les frameworks SPA représentatifs (Next.js, Gatsby, Nuxt, etc.) ajoutent une grande quantité de code JS pour imiter les comportements natifs de base du navigateur
- Le résultat est une naturalité native sacrifiée, une baisse de vitesse et aussi une dégradation du SEO
L’évolution de la plateforme web et le changement de rôle du CSS
- Les navigateurs modernes basés sur Chromium (Chrome, Edge, etc.) prennent désormais en charge des transitions de page natives et déclaratives
- Grâce à la View Transitions API, il est possible de créer des animations fluides entre documents ou entre pages entières sans JavaScript
- Les capacités clés sont les suivantes :
- des effets de fondu entre pages (réalisables en seulement 3 à 4 lignes de CSS)
- des animations d’éléments partagés, comme une transition naturelle d’une miniature vers une image détaillée
- le maintien d’éléments persistants comme les en-têtes ou la barre de navigation
- comme il s’agit de vraies URL et de vraies navigations entre pages, la compatibilité est maximale avec le SEO, le partage de liens et le cache retour/avant
Comment tirer pleinement parti de la synergie entre CSS et JS
- Si nécessaire, on peut aussi déclencher manuellement une View Transition en JavaScript pour des transitions à l’intérieur d’une page
- Exemples : changement de thème, bascule d’onglets, passage au mode sombre, avec une quantité minimale de JavaScript
Speculation Rules et navigation instantanée
- Les Speculation Rules permettent au navigateur de précharger/prérendre des pages en anticipant le comportement de l’utilisateur (par exemple au survol de la souris), afin d’offrir une navigation instantanée
- La configuration peut se faire de manière déclarative via
<script type="speculationrules">
- Condition préalable : l’effet de maximisation des performances est surtout atteint lorsque les pages sont légères et optimisées ; avec des pages lourdes, cela peut au contraire gaspiller des ressources
Respecter les fonctionnalités propres au navigateur et le bfcache
- Le bfcache (Back/Forward Cache) restaure instantanément une page entière sous forme d’instantané lorsque l’utilisateur navigue en arrière ou en avant
- Condition préalable : il faut une architecture propre, basée sur HTML et CSS purs ; cela n’est pas applicable dans des structures qui interceptent le routage comme les SPA
- En conclusion, les navigateurs modernes évoluent dans une direction qui récompense les sites web simples et robustes
Comparaison des performances entre SPA et MPA
- SPA moyen (sur la base de Next.js) :
- taille du bundle JS : 1 à 3 Mo
- TTI (moment où la page devient utilisable) : 3,5 à 5 secondes
- transition de route : fausse / simulée
- SEO : complexe, difficile à maintenir
- comportement du scroll / des ancres : instable
- MPA moderne (avec transitions CSS et Speculation Rules) :
- bundle JS : 0 Ko (hors enrichissements optionnels)
- TTI : autour de 1 seconde
- transition de route : vrai comportement natif
- SEO : très simple
- scroll intelligent, focus, historique : comportement natif du navigateur et prise en charge complète
Repenser la distinction entre site web et application, et leur adéquation
- La grande majorité des sites web ne sont pas de vraies « applications » et n’ont pas besoin d’état partagé, de routage côté client ni d’interactions complexes
- Pour des pages marketing, des portails documentaires, de l’e-commerce ou des blogs, une structure centrée sur HTML, au chargement rapide et simple, est plus adaptée
- Adopter une stack SPA sur tous les projets peut entraîner une complexité excessive et une baisse des performances
- exigence de « ressembler à une application »
- adoption d’un framework
- ajout du routage client et augmentation de la complexité
- dégradation des performances et besoin d’optimisations supplémentaires
- au final, cela reste plus lent qu’une structure de liens natifs + animations CSS
Conclusion et recommandations
- Les SPA relevaient surtout d’une solution de contournement temporaire aux limites passées de la plateforme, mais ces contraintes n’existent plus aujourd’hui
- Il est désormais possible de s’appuyer activement sur les fonctionnalités natives suivantes :
- de vraies transitions entre pages
- du pré-rendu instantané via les Speculation Rules
- une architecture robuste face à la dégradation progressive des fonctionnalités
- un balisage propre, un chargement rapide et l’usage de vraies URL
- une structure capable de tirer le meilleur parti de la plateforme
- Continuer à s’accrocher aux SPA au seul motif de la « fluidité » impose un coût en complexité, performances et maintenabilité
- Avec du rendu côté serveur, de vraies pages, des animations basées sur CSS, du préchargement intentionnel et un minimum de JavaScript, il est possible de créer des sites web rapides et agréables, adaptés à l’époque actuelle
- En tirant parti des technologies disponibles en 2025, il faut viser une expérience web plus rapide, plus simple et plus accueillante pour tous
10 commentaires
À l’origine, dans les cas où l’on envisageait un SPA uniquement pour son côté « fluide », j’aurais simplement renoncé à cette fluidité et développé en MPA, donc j’avoue que je n’y adhère pas vraiment...
Ce qui m’a laissé sur ma faim dans cet article
Le véritable objectif des SPA est interprété de manière réductrice
La View Transitions API est vraiment géniale, mais cela ne suffit pas à rendre les SPA inutiles.
Tous les sites web sont considérés selon les mêmes critères
Site marketing ≠ dashboard ≠ application e-commerce ≠ outil de collaboration en temps réel
Ils ont tous des exigences structurelles différentes.
En pratique, SPA + SSR + MPA coexistent
Les frameworks hybrides comme Next.js le montrent bien.
Les assets statiques relèvent du SSG, les dashboards après connexion du CSR/SPA, et le SSR est utilisé pour le référencement, entre autres : il faut donc une combinaison flexible.
Je pense que les SPA sont moins seulement une question d’expérience utilisateur qu’un produit d’amélioration de l’architecture.
Pour les pages où une SPA n’est pas nécessaire, un MPA + CSS moderne peut être un bon choix, mais les SPA restent indispensables du point de vue de la structure, de l’état, de l’extensibilité et de la maintenabilité. À mon avis, le CSS moderne peut « compléter » les SPA, mais pas les « remplacer ».
Parmi les cas que vous avez présentés, le seul qu’on ne puisse pas remplacer par des SPA avec des view transitions et autres, ce sont les outils de collaboration en temps réel, et la grande majorité des sites web ne sont pas des outils de collaboration en temps réel. Les sites marketing, les tableaux de bord et les apps de commerce peuvent tous être construits en excluant les frameworks SPA, tout en respectant les conditions suivantes : rendu côté serveur, vraies pages, animations basées sur CSS, préchargement intentionnel et recours minimal au JS. Il y a aussi Hotwire, porté par l’écosystème Rails, qui vise justement cela, avec des cas de production comme Basecamp et Hey. La gestion d’état ? Sauf pour quelque chose comme un outil de collaboration en temps réel, des méthodes côté serveur comme les paramètres d’URL ou les sessions serveur, ou encore le stockage local, suffisent largement. Il existe clairement des cas où des SPA sont adoptées pour les transitions de page (comme le site officiel d’AGF, où Astro aurait largement suffi mais où React a quand même été adopté), et on ne peut pas nier que les transitions de page sont souvent citées comme l’un des principaux avantages des SPA.
Il est vrai que les frameworks SPA actuels, ainsi que les tendances frontend qui s’appuient sur eux, doivent continuer à se méfier de la non-standardisation, et qu’ils favorisent facilement l’overengineering ainsi qu’une consommation de ressources inutile…
Cela dit, on a aussi une vision trop étroite du concept même de SPA, et plus encore, je me demande si l’on comprend vraiment quel impact les frameworks SPA ont sur l’ensemble du développement.
Dire qu’avec la seule View Transition API et un peu de CSS, tout est réglé revient, autrement dit, à affirmer que toutes les autres fonctionnalités sans rapport avec cela, ainsi que les paradigmes permettant de les atteindre, sont totalement dénués de sens ; je trouve que c’est une vision assez arrogante.
C’est encore un autre sujet que l’overengineering qu’on constate lorsqu’on construit en React un site qui ne fait guère plus que remplacer une brochure.
Je suis d’accord sur le fait que, pour la plupart des petits projets, un framework SPA n’est pas vraiment nécessaire. Mais pour des services qui exigent des interactions complexes, une expérience utilisateur continue, ainsi que la maintenance et l’amélioration continue qui en découlent, je ne pense pas que ce soit le cas, malgré les progrès du CSS.
Honnêtement, ça donne l’impression de dire à propos de Rust ou Haskell, sans même y avoir touché : « on n’en a pas besoin, aujourd’hui tout est déjà possible en C++ ».
Hum, je ne suis pas sûr. L’objectif d’utiliser un framework SPA n’est-il pas plutôt de gérer des interactions complexes avec l’utilisateur que d’offrir des transitions fluides ?
Il est clair que certains adoptent un framework SPA juste pour une interaction fluide. Pourtant, une grande partie des sites utilisant des SPA n’ont pas besoin d’interactions complexes.
Tout à fait d’accord
À titre d’exemple parlant, React lui-même est en quelque sorte le Spring du front-end
C’est lourd et complexe, et même si on a l’impression que cela facilite le travail, en réalité on met en place un processus plus compliqué pour accomplir des tâches simples, puis on se retrouve avec cette étrange forme de confort qui consiste simplement à rendre ce processus inutilement complexe plus pratique
Je suis d’accord. À moins qu’il ne s’agisse d’une web app complexe comme Google Docs, je pense que Howired, créé dans l’écosystème Rails, suffit largement, et qu’Astro suffit aussi pour les pages statiques.
Avis Hacker News
Les SPA ont du sens quand les utilisateurs passent de longues sessions dans une même application : on charge un gros bundle une seule fois, puis l’application fonctionne ensuite avec seulement de petites requêtes réseau. Les transitions fluides ne sont qu’un bonus ; selon moi, ce n’est pas le problème fondamental que résolvent les SPA. Dire que le routage côté client sert avant tout aux transitions de page, c’est mal comprendre l’objectif des SPA. Si on les a utilisées sur cette mauvaise prémisse, alors cet article a raison, mais les SPA sont apparues à l’époque de jQuery pour les applications complexes : d’énormes amas de code jQuery où chaque
divse comportait comme une mini-app et se synchronisait via de nombreuses petites requêtes réseau. Sur des navigateurs anciens et des connexions lentes, cela permettait d’éviter de recharger tout le code à chaque fois. Ensuite, des frameworks comme React ont facilité le développement structuré d’applications, et l’avantage central des SPA reste de pouvoir mettre en cache un gros bundle pour les utilisateurs ayant de longues sessions, puis de minimiser le trafic réseau ensuite.(Citation de l’avis ci-dessus : "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Je suis tout à fait d’accord. L’auteur est consultant SEO et semble se focaliser uniquement sur les sites marketing. Les vraies applications (pas les sites marketing) peuvent tirer de gros bénéfices des SPA. Par exemple, si on imagine Google Maps sans SPA, même avec des animations de transition entre pages, l’UX serait gravement dégradée.
Il y a cette formule, « on a juste empilé du spaghetti jQuery », mais en réalité j’ai appliqué des patterns de conception JS plus anciens comme les IIFE pour structurer le code, faire du chargement différé de modules, de l’obfuscation, etc. Et d’après mon expérience, AngularJS a été la plus grande tentative de structuration du frontend, et ce qui le rendait attrayant pour les développeurs Java, c’était la modularisation, la DI et la facilité de test. Au début, quand je faisais des apps avec Backbone, je ne me souciais pas trop des tests parce que je pensais que la plupart des fonctionnalités resteraient côté backend. Plus tard, en reconstruisant avec AngularJS, j’ai eu beaucoup plus de tests frontend. Cela dit, aujourd’hui je ressens un rejet face à la verbosité, la complexité et l’indirection du code Angular moderne ou du code Java.
Je pense qu’une connexion réseau lente combinée à une mise en cache agressive est l’une des meilleures justifications des SPA, surtout pour des applications plutôt que des sites web. Si on peut télécharger tout le frontend d’un coup avec une connexion correcte et le mettre en cache, l’usage ultérieur peut se faire avec une bande passante minimale.
Si vous travaillez dans un environnement qui utilise des pipelines CI/CD modernes, le gros bundle JS a de fortes chances d’être reconstruit et de voir son cache invalidé à chaque déploiement, parfois plusieurs fois par jour. HTTP2 est déjà activé par défaut dans les navigateurs depuis dix ans, et son multiplexage supprime la nécessité de regrouper le JS en gros bundles. L’approche SPA qui fabrique de gros bundles n’exploite pas les capacités modernes des navigateurs et des serveurs.
Je me demande combien il existe réellement de cas où les requêtes réseau deviennent vraiment minuscules après le chargement initial. La plupart des SPA que j’ai vues continuaient à faire de gros appels après le chargement, et étaient bien plus lentes que le simple fait d’envoyer directement du HTML. L’idée que le JSON se compresse magiquement mieux que le HTML ne tient pas non plus : le HTML se compresse très bien. En pratique, l’argument selon lequel les SPA sont meilleures à cause du réseau relève presque de la propagande ou de la superstition.
À mon avis, la valeur des SPA ne se limite pas aux transitions fluides ; elle tient aussi au fait qu’on peut gérer l’essentiel du parcours utilisateur côté client sans presque se soucier du serveur. Par exemple, ça me frustre qu’en 2025 la plupart des boutiques en ligne rechargent encore toute la page et refassent un aller-retour serveur dès qu’on change un filtre ou qu’on entre dans une catégorie. Quand un utilisateur navigue entre catégories et déclenche plusieurs requêtes, l’UX serait bien meilleure si tout le catalogue était téléchargé une fois côté client, puis filtré sans communication supplémentaire avec le serveur. On objectera que le volume de données est important, mais dans la plupart des boutiques, une catégorie tient en quelques KB, donc moins qu’une seule image produit. Cela fait depuis 2005 que je construis ce genre d’applications, et je ne comprends toujours pas pourquoi cette UX n’est pas plus répandue.
Selon moi, ce qu’il y a de plus gênant dans le fait de devoir recharger complètement une page, ce n’est pas tant le volume de données que l’efficacité globale du site. Les données réelles font quelques KB, mais la page elle-même télécharge 100 MB et le navigateur consomme 1 GB de RAM. Par exemple, Hacker News repose surtout sur des rechargements de navigation et fonctionne bien même sur de vieux laptops. À l’inverse, un SPA comme DoorDash mettait 30 secondes sur la même machine, et il fallait plus de 3 minutes pour réellement commander à manger. Il fallait attendre 2,5 minutes rien que pour voir l’interface, et presque rien de tout cela n’était dû à des rechargements complets.
Des outils comme HTMX règlent une bonne partie de ce problème. À mes yeux, l’approche SPA revient finalement à créer deux applications distinctes : un frontend et un backend. Je préfère largement faire l’essentiel côté serveur et n’ajouter côté client que des effets interactifs simples (afficher/masquer, développer/réduire, effets visuels, etc.). Bien sûr, il existe des cas où les SPA sont utiles.
Dans un registre proche, j’héberge certains projets personnels sur un serveur web statique. Au lieu de rendre des dizaines de milliers de pages individuelles, je fournis un fichier JSON unique que la SPA rend côté client. J’ai aussi utilisé GitHub Pages. Récemment, j’expérimente une architecture qui s’appuie sur une build wasm d’une base de données sqlite, avec des HTTP Range Requests pour ne récupérer que les pages nécessaires. La Full Text Search de sqlite fonctionne aussi, mais pour les recherches courtes il faut charger toute la table, ce qui est dommage. Il vaudrait peut-être mieux télécharger toute la base puis construire localement la table FTS.
On peut aussi citer des contre-exemples. Par exemple, si on fait Shift-clic sur la catégorie « sci-fi » pour l’ouvrir dans un nouvel onglet, cela fonctionne sans effort particulier en MPA, alors qu’en SPA il faut gérer ce comportement explicitement, ce qui est pénible. Et si l’accès à la catégorie ne se fait pas par un lien mais seulement par une
select box, l’UX est médiocre.En général, les entreprises ne veulent pas que l’utilisateur télécharge l’intégralité du catalogue, car un concurrent pourrait l’analyser facilement. Et dans des cas comme la vente de livres, où le catalogue compte des centaines de milliers de titres, tout transférer d’un coup est inefficace aussi bien du point de vue de l’expérience utilisateur que de la bande passante et de la mémoire.
Le but des SPA n’a absolument jamais été les transitions entre pages. Très peu de SPA implémentent correctement de bonnes transitions. Par exemple, dans Next.js, à cause de la manière dont les routes se chargent, il est quasiment impossible de faire correctement des transitions de page. J’ai moi-même essayé d’ajouter une vraie fonctionnalité de transition dans Next.js, et c’était un cauchemar absolu. À mes yeux, les avantages clairs des SPA sont au nombre de deux. D’abord, la plupart des applications veulent un certain niveau d’interactivité, et comme HTML/CSS seuls ne suffisent pas, mélanger React et du HTML pur est extrêmement pénible, surtout lorsqu’il faut gérer un état global. Ensuite, si toute la structure de la page est préchargée, le chargement des données suivantes est plus rapide, et du point de vue UX, une réaction immédiate au clic avec un écran de chargement vaut mieux qu’une réaction qui n’arrive qu’au bout de 500 ms — sauf si on reste sous les 100 ms, bien sûr. Comme il n’est pas nécessaire de tout redessiner, les performances frontend restent hors de portée du HTML seul. Il existe des cas comme Basecamp, qui a très bien construit une application web complexe sans SPA, mais même après 30 secondes à cliquer un peu partout, on sent que ça n’atteint pas les performances d’une SPA. J’aimerais que le web fonctionne davantage comme le web, mais si Next.js et les SPA ajoutent de la complexité, ils ont aussi rendu les applications plus rapides et plus réactives, au prix d’un développement plus pénible et de gros bundles. Malgré tout, je pense que le HTML seul ne peut pas encore égaler les performances des SPA.
Je ne sais pas dans quel univers vit ce consultant SEO qui a écrit l’article. Prendre Next et Nuxt comme exemples de frameworks représentatifs de l’opposition aux SPA est complètement faux. 1. Next a pratiquement tout raflé aux États-Unis et dans le monde occidental ; quand on parle d’une nouvelle app React, on désigne généralement Next. Côté Vue, Nuxt est presque le standard, et Nuxt = le Next de l’écosystème Vue. Autrement dit, les gens choisissent déjà inconsciemment Next et une stratégie MPA. Le pendule a tellement basculé vers les MPA qu’au contraire, je recommanderais d’essayer les SPA. Les huit dernières années ont été une période d’engouement pour les MPA, et même Facebook recommande désormais officiellement Next dans sa documentation à la place de Create React App. 2. Les plaintes sur la complexité de Next concernent la difficulté des stratégies MPA modernes ; côté SPA, le discours est resté presque figé depuis dix ans. 3. Le développement MPA est bien plus difficile que le développement SPA, parce qu’il faut respecter beaucoup plus strictement la séparation serveur/client. 4. Si l’on veut charger des données « façon MPA » dans une SPA, c’est un choix du développeur, à lui d’en assumer les avantages et les inconvénients. On peut aussi précharger les données pour obtenir une navigation SPA instantanée. 5. Au-delà du frontend principal où le SEO est crucial, il existe encore davantage de dashboards internes et d’applications. C’est souvent là qu’on trouve les développeurs React, et il est important de ne pas s’imposer un fardeau inutile en voulant absolument fournir un premier rendu parfait dans tous les cas.
Je trouve injuste le ton dépréciatif envers les SPA. Elles demandent certes plus d’efforts, mais elles offrent aussi nettement plus d’avantages. Pendant longtemps, les SPA ont été la seule manière de produire une UX qui donne vraiment une sensation d’application. L’auteur évoque la fatigue face aux apps, mais si l’on veut proposer une véritable expérience « applicative », les SPA sont pratiquement la seule option. Comparer une SPA lourde à un site web léger — par exemple un site statique — n’a pas de sens. Si quelqu’un peut construire un site léger, il peut tout aussi bien construire une SPA légère. Qu’il s’agisse d’une SPA ou d’un site web, si c’est mal conçu, ce sera lent et lourd dans les deux cas. En tant que personne ayant beaucoup investi dans les SPA, je me suis beaucoup intéressé aux moyens d’obtenir la même expérience avec moins d’efforts, mais cet article ressemble davantage à un peu d’habillage visuel. Les règles de style ont de la valeur, mais pas au point de déterminer à elles seules le choix entre SPA et non-SPA.
« Essayez donc de créer linear.app sans framework SPA » me paraît irréaliste. L’idée selon laquelle « les transitions CSS natives ont tué le principal avantage des SPA, c’est-à-dire le routage côté client » n’a aucun sens.
Je pense que Linear est un cas très particulier, même parmi les SPA. Il ne s’agit pas d’interdire les SPA ni de supprimer totalement le JS dans le navigateur. Si Linear est rapide, c’est grâce à sa conception « offline-first », mais très peu de services fonctionnent ainsi. Pour la billetterie, les forums, l’actualité, les blogs ou les sites d’information, je pense qu’un développement basé sur le SSR est bien préférable. Il vaut mieux réserver les SPA aux cas où elles sont vraiment nécessaires, développer rapidement le reste en SSR, puis utiliser le CSS pour donner une apparence proche d’une SPA.
Les SPA ont leur place, mais les 99 % restants des sites n’ont pas besoin d’être des SPA.
Les SPA n’ont pas pour objectif les view transitions. Le texte original (TFA) laisse entendre à tort que des transitions spectaculaires entre pages sont importantes ; au lieu de blâmer les « CMO » ou les « brand managers », il faudrait mettre en lumière la vraie valeur des SPA. Les SPA sont un excellent framework pour la logique cliente, la séparation des responsabilités (logique frontend séparée du backend), l’amélioration de l’expérience développeur, donc une vitesse de développement plus élevée, etc. Si l’on voit autant d’articles de ce genre, c’est parce que leur structure appelle la controverse, comme mon propre commentaire, mais en réalité ce n’est pas un texte qui mériterait autant d’attention.
De mon point de vue, la principale promesse des SPA n’est pas la fluidité des transitions, mais le fait de construire un frontend et une API de données complètement découplés du backend. C’est pour cela que je n’aime pas mélanger SSR et rendu côté client. À mes yeux, on devrait être soit clairement sur un site web, soit clairement sur une application.
Je me demande aussi : « quel est exactement le critère qui distingue SPA et MPA ? » Mon site personnel basé sur Next.js rend en pratique presque tout côté serveur. Techniquement, c’est une SPA, mais si le JS est activé, on a RSC et la navigation côté client ; si le JS est désactivé, les composants purement client (par exemple un générateur de QR code) affichent un contenu de remplacement et tout le reste est rendu entièrement en SSR, ce qui reste un peu plus lent mais fonctionne très bien. Ne pas rendre les composants côté serveur demande en fait plus de travail. Le progressive enhancement, c’est le top.
Window loadde l’application se déclenche.Et puis il est vraiment frustrant de voir le milieu du SEO ou les jeunes développeurs web arrivés après le Covid mal comprendre et rabaisser sans cesse les SPA. Du point de vue de quelqu’un qui développe depuis les années 2000, l’origine réelle des SPA n’a rien à voir avec la « fausse promesse » évoquée dans l’article, mais avec la diffusion des stratégies mobile-first à la fin des années 2000 et au début des années 2010, qui imposaient une séparation complète entre frontend et backend. Avant cela, le frontend consistait généralement à rendre du HTML via des templates côté serveur, avec un peu de jQuery par-dessus. Mais aujourd’hui, les apps mobiles et desktop doivent partager la même logique métier et la même base de données ; on a donc relu les thèses autour de REST et les travaux de Roy Fielding, et l’architecture orientée services ainsi que l’exposition d’API externes sont devenues dominantes. Il y avait aussi un aspect d’optimisation des coûts. Pendant cette période, des frameworks web full-stack comme Ruby on Rails ou Django ont traversé un moment de creux. Avec la montée de Node.js, les navigateurs et les mobiles sont devenus de plus en plus puissants, ce qui a permis de déplacer une grande partie de la logique métier vers les « edge devices », c’est-à-dire le client. C’est cela, le point central des SPA. Le CSS ne peut pas remplacer ce besoin.