Réponse à @Saint_loup – https://twitter.com/Saint_loup/status/910627517719072768
Coté front-end, "bien" faire un site web ecommerce sous forme d'une SPA full JS pose des défis très critiques (webperf / accessibilité / seo – mais aussi staffing, organisationels, etc...) qui sont déjà très bien assurés nativement par une approche plus classique (pages HTML/CSS "statiques" bien écrites, dynamisées par une couche de JS bien écrit).
Certes, c'est possible de résoudre certaines choses en "full JS", avec du rendu coté serveur (approche en voque chez les "pure players" – qui ont un SI peu "épais"). Mais de même : nouveaux défis backend, il faut tout changer et ré-écrire coté serveur (sur pas mal de parties qui contiennent de la logique métier).
L'approche "classique" est d'avantage retro-compatible et futur-compatible :
- rien n'interdit d'y "saupoudrer" du preact ou de vueJS, par exemple)
- tu n'es pas coincé lorsque ton super framework sur lequel tu as tout basé (et que tu auras bien customisé) devient obsolète 1 à 2 ans plus tard.
Dans le contexte actuel du projet sur lequel je travaille, AMHA, le scenario "SPA" full JS, là tout de suite, maintenant" n'est pas la voie la plus solide.
(reprise des réponses ;) )
Mes préoccupations sont essentiellement d'ordre de l'ingénierie. Il est tout à fait possible d'avoir une ergonomie de type applicative sur une structure classique (avec des URLs signifiantes et des pages qui s'affichent "même sans JS").
Ce que je veux absolument éviter au stade actuel du projet – très gros, qui tourne déjà en prod, et qui a déjà du mal à "scaler" humainement, fonctionnellement et techniquement sur ses cibles – c'est un bouleversement trop profond et trop prématuré qui va créer des défis supplémentaires alors que les défis existants ne sont que peu ou mal adressés ; je milite pour un chemin d'évolution plus raisonné et progressif.
C'est pas évident d'en parler (du projet, et de son stade actuel) sans donner trop de détails ;)
D'un point de vue ergo, donc ? Les interactions utilisateur très dynamiques, basées sur une structure de code évènementielle et solide sont facilitées par certains composants utilisés dans les SPA (ie React dans une stack next.js par exemple), mais pas par le fait d'être une SPA en elle même.
"Ça dépend" (désolé :-/ ) déjà de ce que l'on appelle "web app" (personne n'est vraiment d'accord ^^) et de tellement de paramètres contextuels : l'UX désirée et donc de l'offre (sa nature, sa structuration, son volume), la stratégie globale et la nature du vendeur, les pays cibles, leur propre stratégie et spécificités.
En général, sur les débats actuels dans la communauté front-end, je me situe pile au milieu entre les "maximalistes JS" et les "luddites oldschool", position qui n'est pas toujours facile à expliquer :)