JavaScript réactif : l’évolution de l’architecture frontale

L’architecture frontale est l’un des domaines les plus dynamiques du développement logiciel aujourd’hui. Plusieurs innovateurs poussent l’état de l’art pour concevoir des moyens plus puissants de créer des interfaces utilisateur dynamiques. Une grande partie de ce travail se déroule à un rythme effréné et au grand jour.

Grâce à un certain nombre de projets JavaScript open source, tels que SvelteKit, Solid, React, Qwik et Astro, nous sommes aux premières loges de l’évolution de l’avenir du Web. Voici un guide pour comprendre l’action.

Qu’est-ce que l’hydratation ?

Une grande partie de l’activité autour de l’amélioration de l’architecture frontale moderne se concentre sur ce qu’on appelle hydratation. Pour comprendre ce qu’est l’hydratation et pourquoi elle est au cœur de l’architecture frontale moderne, examinons les concepts de haut niveau en jeu. Pour offrir la merveille de la réactivité, chaque framework doit gérer les trois aspects illustrés dans le schéma ci-dessous.

IDG

Le message de base dans le diagramme est que le cadre est chargé de cadrer la vue, de maintenir l’état et de gérer l’interaction entre eux. (Si vous connaissez le modèle MVC, vous l’entendrez ici.)

Une fois ces trois pièces en place, vous êtes prêt à partir. L’utilisateur peut voir la page et interagir avec elle.

L’approche naïve, ou par défaut, consiste simplement à prendre tout ce dont le client a besoin (le cadre, le code réactif et l’état) et à l’envoyer. Le client (le navigateur) effectue ensuite le travail d’affichage du cadre (c’est-à-dire de peinture de l’interface utilisateur), d’interprétation du JavaScript et de lier l’état.

Cette approche a le merveilleux avantage de la simplicité, à la fois pour le code au travail et pour les esprits humains essayant de le comprendre. Il a également un gros inconvénient : le rendu initial de la page doit attendre tout, et l’utilisateur doit s’asseoir à travers tout ce réseau et ce navigateur. De plus, à moins que des précautions ne soient prises, la page aura tendance à s’afficher puis à se réorganiser de manière embarrassante dans la mise en page finale. Pas un bon look.

Cela a inspiré les développeurs à essayer d’abord de rendre la page initiale sur le serveur (rendu côté serveur ou SSR) et envoyez-le. Ensuite, l’utilisateur a une page décente à regarder pendant que le reste du code et de l’état est envoyé et amorcé. C’est une grande simplification mais c’est l’idée de base.

Le temps qu’il faut pour mettre en place la mise en page de base s’appelle première peinture contente (FCP). Le prochain jalon que la page doit atteindre est mesuré par temps d’interactivité (TTI), c’est-à-dire le temps jusqu’à ce que l’utilisateur puisse réellement utiliser la page.

Le processus consistant à prendre la page initiale et à la rendre interactive, c’est-à-dire hydratation.

Limites du rendu côté serveur

L’essentiel est que le SSR a tendance à améliorer le FCP mais à aggraver le TTI. Ainsi, l’objectif est devenu de trouver un équilibre entre les deux tout en les maximisant tous les deux, tout en maintenant, espérons-le, une expérience de développement agréable (DX).

Diverses approches ont été proposées, adoptées, abandonnées, modifiées et combinées dans cet effort pour améliorer l’hydratation. Une fois que l’on commence à regarder les détails de la mise en œuvre, on est étonné de voir à quel point cela devient complexe. Une amélioration équilibrée de FCP et TTI avec un DX décent ? Cela semble facile, mais ce n’est pas le cas.

L’une des raisons de la complexité est que nous sommes en plein milieu du tri de tous les compromis ; c’est une scène qui se déroule. Une fois que la voie à suivre se cristallise cependant, nous devrions nous attendre à deux résultats de l’architecture client qui émerge. Tout d’abord, il devrait créer des applications Web qui se sentent “nouvelle génération”, de la même manière que les applications bien construites offrent aujourd’hui une expérience subtile mais clairement meilleure que celle d’il y a quelques années.

Deuxièmement, et peut-être plus important encore, notre architecture client améliorée devrait avoir des conséquences considérables au-delà de meilleures performances. En abordant et en résolvant la complexité, les ingénieurs frontaux arriveront à un meilleur modèle, à la fois pour le système et pour l’esprit. Une meilleure architecture représente en fait une heuristique plus puissante. Il en résulte des avantages ultérieurs souvent imprévisibles.

Vous pouvez voir cela en action avec la réactivité elle-même. La réactivité a fait irruption sur la scène car elle offrait un moyen de décharger la liaison d’état du cerveau du développeur vers le framework. Mais les avantages ne se sont pas arrêtés là. L’architecture est devenue non seulement plus simple, mais plus cohérente. Ces performances et fonctionnalités nettes gagnent à tous les niveaux.

Étant donné que les frameworks JavaScript modernes intègrent à la fois le serveur et le client, les résultats de ces développements peuvent avoir de vastes conséquences pour l’architecture des applications en général.

Approches pour améliorer l’hydratation

L’astuce de base pour améliorer la situation d’hydratation est de regarder les choses de manière plus granulaire. En divisant la vue, l’interaction et l’état en plus petits morceaux, nous pouvons les charger et les activer par étapes, optimisés pour FCP et TTI. Voici une visite de certaines des approches.

Éviter complètement JavaScript

Une approche qui a été absorbée dans les meilleures pratiques consiste à analyser les sites pour les pages qui ne nécessitent pas du tout JavaScript. Cela se rapporte à la nouvelle notion de applications multipages (AMP). C’est une sorte de compromis entre les applications à page unique (SPA) et la navigation directe par page (comportement Web par défaut). L’idée ici est de trouver les parties de l’application qui peuvent être expédiées immédiatement sous forme de ressources HTML plus, ce qui se traduit par les meilleurs temps de chargement et de référencement possibles.

L’approche sans JS est vue dans SvelteKit, par exemple. Cela ne fait rien pour les pages qui nécessitent une interaction réactive, bien sûr. Les cadres doivent encore traiter l’hydratation sur les pages qui agissent comme SPA.

Architecture insulaire

Astro a défendu l’idée de architecture insulaire. L’idée est de déterminer quelles parties de la page sont statiques et quelles parties nécessitent de la réactivité. Avec cette connaissance, vous pouvez affiner le chargement de la page en ignorant entièrement le contenu de cadrage qui ne change jamais, puis en chargeant les autres parties (les îles) uniquement si nécessaire.

Il est utile pour approfondir cette idée de noter qu’elle vise à améliorer le SPA. C’est-à-dire que tout le contenu statique que vous identifiez peut simplement rester là, faire son travail sans aucun impact sur les performances. Tout votre état et votre navigation côté client sont maintenus.

Du côté positif, cette approche vous permet de retarder le chargement de chaque île jusqu’à ce que quelque chose le rende nécessaire (par exemple, défilement dans la vue, un clic de souris). En revanche, dans la pratique, cela se traduit souvent par des charges qui se produisent à un moment particulièrement inopportun (juste au moment où l’utilisateur fait quelque chose).

Limites paresseuses

Des fonctionnalités telles que le composant Suspense de React offrent une approche qui maintient le modèle d’hydratation de base en place, mais le décompose le long de limites puis chargé paresseusement. Cela a l’avantage de conserver une grande partie du processus familier en place, mais l’inconvénient de nécessiter beaucoup de réflexion et de réglage de la part du développeur pour obtenir de bons résultats. Mentalement, le développeur est en mesure de faire le pont entre le monde de la disposition des composants et le fractionnement du code au moment de la construction.

De plus, le chargement paresseux ne peut pas être très utile, car une grande partie du framework doit encore être expédiée à l’avance.

Possibilité de reprise

La possibilité de reprise est une idée qui a été introduite par le framework Qwik. Qwik plonge plus profondément dans les éléments de l’application et crée des limites paresseuses entre eux. (D’une certaine manière, vous pourriez le voir comme une forme hautement sophistiquée de limites de chargement paresseux.) La capacité de reprise signifie que le client peut reprendre là où le serveur s’est arrêté et garder les choses synchronisées de manière fine.

Composants du serveur

React déploie l’idée de composants de serveur et une amélioration des performances associée appelée streaming. Voici une description du fonctionnement des composants du serveur. Essentiellement, les composants serveur vous permettent d’identifier quelles parties de l’application peuvent être exécutées entièrement sur le serveur, évitant ainsi toute pénalité de rendu côté client.

Diffusion

Le streaming est une autre technique React évolutive liée au Suspense. L’idée ici est de permettre au contenu de cadrage comme HTML de commencer à être expédié au client avant même que toutes les données requises ne soient prêtes sur le serveur. Cela peut ensuite être appliqué lorsque l’interaction des composants se produit.

Hydratation partielle ou hydratation progressive

Les choses deviennent un peu boueuses avec ces termes. Astro décrit son architecture insulaire comme hydratation partielle. C’est simplement pour dire que seuls certains éléments de la page sont hydratés à la fois. Ceci est aussi parfois appelé hydratation progressive Ces deux termes sont parfois appliqués à d’autres techniques.

Nous avons vraiment trois termes ici qui se marchent sur les pieds : îles, partiels, progressifs. Peu importe, l’idée principale est la même : nous devons décomposer la structure de l’application en plus petits morceaux afin de la faire charger plus intelligemment.

Hydratation cloisonnée ?

Essayons de démêler un peu les termes. Disons que l’architecture insulaire fait référence à des morceaux d’interaction indépendante de style Astro dans un cadre statique.

En remontant, on pourrait dire que toute l’idée de décomposer l’interface utilisateur est une hydratation partielle, et les îles d’Astro en sont un exemple. Nous ne pouvons pas le faire sans péril, cependant, car Astro == island == partial flotte déjà là-bas. Aussi, partiel semble suggérer un état d’hydratation incomplet, ce qui est trompeur.

puis encore, progressive invite à la confusion avec les applications Web progressives (PWA). Peut-être hydratation cloisonnée est un bon terme pour l’idée globale.

Évolution de l’architecture frontale

L’activité autour de l’architecture frontale de JavaScript a créé certains des travaux de code les plus intéressants que j’aie jamais vus. C’est un espace plein d’individus passionnés qui explorent de nouveaux territoires conceptuels et font la programmation révolutionnaire qui va avec. Et ils interagissent et partagent leurs idées de manière ouverte et collaborative. C’est un plaisir à regarder.

Parmi ces personnes figurent Ryan Carniato (Solid) et Misko Hevery (Qwik). Les deux poussent l’état de l’art, libérant du code et des informations au reste du monde au fur et à mesure. Deux bons endroits pour commencer avec le travail de Carnatio sont ici et ici, et deux pour Hevery sont ici et ici.