- Certains développeurs pensent que les frameworks SPA (React, AngularJS, etc.) sont indispensables pour créer des applications de haute qualité
- Pourtant, même avant les SPA, les applications basées sur des MPA offraient déjà une excellente expérience utilisateur
- J’ai essayé de développer une plateforme d’observabilité orientée données en m’appuyant sur HTMX, et avec des optimisations adaptées, un MPA rendu côté serveur peut lui aussi offrir d’excellentes performances et une très bonne expérience utilisateur
Idées reçues et réalités autour des MPA
Idée reçue 1 : les MPA sont lents lors des changements de page
- Problème : le navigateur retélécharge par défaut le JavaScript et le CSS à chaque transition de page
- Solution :
- Utiliser des bibliothèques comme PJAX, Turbolinks ou HTMX Boost pour ne remplacer que le
body HTML
- Exploiter un service worker pour améliorer la mise en cache des pages et le traitement des requêtes
- Exemple : avec un service worker, le temps jusqu’à
DOMContentLoaded est passé de 2,9 secondes à 500 ms
Comment implémenter un service worker
- Créer le fichier
sw.js : écrire le script de mise en cache et de gestion des requêtes réseau
- Définir la liste des fichiers à mettre en cache : HTML, CSS, JS et autres ressources principales
- Définir la stratégie de cache : conserver durablement les ressources statiques ou les rafraîchir périodiquement
Idée reçue 2 : un MPA ne peut ni fonctionner hors ligne ni stocker les requêtes à rejouer après le retour du réseau
- Un service worker permet à l’application de fonctionner même hors ligne
- Utilisation de Workbox :
- Mettre en cache les requêtes en cas d’échec réseau et les réessayer dans les 24 heures
- Définir un gestionnaire hors ligne pour fournir un contenu de remplacement lors des requêtes
Idée reçue 3 : les MPA provoquent un scintillement de l’écran lors des changements de page
- Solution :
- Retarder le rendu à l’écran avec un service worker et l’API de préchargement jusqu’à ce que les ressources soient prêtes
- Depuis 2019, les navigateurs gèrent les transitions au sein d’un même domaine sans scintillement
Idée reçue 4 : il est impossible de créer des effets de transition de page sophistiqués avec un MPA
- Les SPA sont connues pour leurs animations de transition de page, mais les navigateurs commencent aussi à les prendre en charge
- Dans Chrome 126, il est possible d’implémenter des animations de transition entre documents uniquement avec du CSS
- Lien de démonstration
Idée reçue 5 : avec HTMX ou les MPA, toutes les actions utilisateur sont traitées côté serveur
- HTMX est conçu pour que seules certaines opérations soient traitées côté serveur
- Si nécessaire, on peut ajouter des fonctionnalités interactives côté client avec des WebComponents ou un framework JavaScript
- Il est possible d’appliquer une approche SPA seulement à certains composants
Idée reçue 6 : manipuler le DOM est lent, donc React/Virtual DOM est nécessaire
- Le Virtual DOM ne montre une différence de performance que dans des applications extrêmement complexes
- Dans la plupart des applications classiques, manipuler directement le DOM est largement assez rapide
- Référence : "Virtual DOM is pure Overhead"
Idée reçue 7 : même les petites fonctions interactives nécessitent du JavaScript
- Les technologies récentes des navigateurs permettent d’implémenter diverses fonctionnalités sans JavaScript
- Une case à cocher HTML et du CSS peuvent suffire pour créer un mécanisme de bascule
- En combinant cela avec HTMX, on peut charger des données de manière asynchrone au clic
Dernière idée reçue : sans SPA, le code côté client finit forcément en code spaghetti
- Même à l’époque du code spaghetti, beaucoup de logiciels productifs ont été développés
- Au tout début d’un MVP, une structure simple peut être plus avantageuse
Conclusion
- En 2024, les navigateurs ont beaucoup progressé en intégrant les enseignements tirés de la révolution SPA
- Avec les seuls outils natifs du navigateur (HTML, CSS, JavaScript), il est déjà possible de créer des applications interactives capables de fonctionner hors ligne
- Il vaut la peine de refaire confiance au potentiel du navigateur et de l’exploiter à nouveau
8 commentaires
Quand on essaie de développer avec des développeurs tout juste moyens, on comprend tout de suite à quel point ce discours relève du fantasme. L’auteur de ça semble soit entouré de génies, soit travailler seul... (rien qu’à voir qu’il mentionne encore AngularJS, complètement dépassé, on s’en doute). Et puis le développement ne se fait pas uniquement avec des génies.
Certains diront avec mépris que « les gens du même milieu restent entre eux », mais les changements ont toujours été portés par des gens ordinaires.
Quand je vois ce genre de chose, ma première pensée est qu’htmx ne devrait absolument pas être adopté.
C’est un sujet qui revient encore et encore ces derniers temps,
il existe une vidéo où Rich Harris a donné son avis sur ce sujet il y a quelques années.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Si je me souviens bien, on peut résumer cela ainsi : les approches basées sur des mises à jour à partir de HTML partiel peuvent entraîner un risque d’incohérence entre l’interface et les données.
Tu fais encore confiance aux spécifications des navigateurs...?
À vrai dire, je pense que les SPA sont une manière de développer des applications qui dépend un peu moins du comportement des navigateurs.
Il est vrai que les navigateurs ont plutôt bien rattrapé les belles possibilités offertes par les SPA, et que cela semble mieux correspondre au mode de communication pour lequel HTTP a été conçu à l’origine. Mais si c’est le cas, n’est-ce pas parce que Chrome a acquis une position de quasi-monopole dans l’univers des navigateurs, ce qui lui a donné une certaine marge de manœuvre...? Je ne sais pas si cela durera longtemps, que ce soit cette marge de manœuvre ou sa part de marché...
Avec une approche comme Phoenix LiveView, où le DOM est manipulé côté serveur via des WebSocket, on est dans un paradigme différent.
Quand j’ai essayé htmx, le fait de devoir renvoyer des fragments de HTML depuis le serveur ne m’a pas vraiment emballé.
Surtout pour la partie CSS : si on renvoie des classes définies côté serveur, celui-ci ne peut pas savoir quels styles sont effectivement utilisés à l’écran, donc au final on a un peu l’impression que cela impose un CSS commun.
Il y a quelques années, j’ai essayé de créer une UI assez complexe avec Phoenix LiveView, mais implémenter des interactions simples était beaucoup trop compliqué et, comme un LiveView est géré par un processus Elixir, les interactions avec les composants voisins sont très difficiles. Au final, j’ai abandonné et je suis revenu à React.
J’ai l’impression que LiveView, c’est l’avenir… pour moi.
Comme LiveView dépend aussi fortement du réseau, il montre de grosses faiblesses quand le serveur est distant et que le ping est élevé, ou dans des situations où l’infrastructure Internet est mauvaise, comme dans les pays en développement.
Commentaire Hacker News
Certains se demandent pourquoi l’article ne mentionne pas la manière de gérer les ressources CSS et JS statiques en tirant parti du cache du navigateur. Lorsqu’ils construisaient autrefois des sites e-commerce en mode MPA, les changements de page étaient à peine perceptibles.
Certains affirment que le développement web à l’époque de PHP et jQuery était le plus productif. Un avis s’interroge sur la possibilité que les anciens paradigmes aient été plus productifs que les technologies modernes comme React. De grands sites comme Amazon ou Steam sont eux aussi encore construits avec du HTML rendu côté serveur, auquel on ajoute du JS.
Un commentaire demande en quoi la stratégie des service workers est meilleure que les en-têtes de cache HTTP classiques. Cela peut réduire les allers-retours réseau, mais donne aussi l’impression de tout réinventer pour une petite optimisation.
Le titre, « You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths », donne une impression de piège à clics à cause de la partie omise de son sens.
La chose la plus dangereuse en programmation serait l’ennui du développeur et l’ignorance du passé.
Certains disent ne pas comprendre pourquoi cette dichotomie entre côté serveur et côté client (SPA) existe à l’ère des serveurs web Node.js. Ils se demandent s’il ne serait pas possible d’initialiser l’essentiel du travail sur le serveur, puis de le sérialiser vers le client pour fonctionner comme une SPA.
Il existe une tendance à voir SPA et MPA comme deux camps opposés, mais on peut aussi distinguer une utilisation naturelle de la stack web d’une approche « hackée ». La SPA relève aujourd’hui de cette approche hackée, comme CGI, les applets Java ou Flash autrefois. Les approches hackées servent à repousser les limites de la méthode naturelle.
Avant même de décider de la stack technique, les développeurs comprennent souvent mal ce qu’ils sont en train d’écrire. Si un haut niveau d’interactivité n’est pas nécessaire, un framework côté serveur peut suffire dans la plupart des cas.
On trouve aussi une réfutation du mythe selon lequel « on ne peut pas créer d’application web interactive sans application monopage ». Les SPA offrent davantage de contrôle et réduisent le risque de devoir retravailler certaines parties du code.
Le titre HN est plus agressif que le vrai titre. Il s’agit d’un essai présenté par Tony Alaribe à la BigSkyDevCon, qui traite des techniques permettant de rendre les applications web non fondées sur les SPA rapides et fluides. Il y présente de nouvelles techniques, et certains estiment que c’était la meilleure intervention de la conférence.