Évolution de la technologie Web et des navigateurs

Hé, là ! Vous êtes-vous déjà demandé comment fonctionne exactement le Web et que se passe-t-il réellement lorsque vous entrez une URL dans votre mystérieux navigateur ? Ne vous inquiétez pas, vous n'êtes pas seul — la plupart d'entre nous traitent le Web comme une sorte de boîte noire. Mais puisque vous avez cliqué sur ce blog, j’imagine que vous voudrez peut-être y jeter un coup d’œil. C'est fantastique ! La curiosité a peut-être tué le chat, mais pour les développeurs, c'est la sauce secrète.

Même si vous en savez un peu plus sur son fonctionnement, vous pourriez encore vous demander pourquoi cela a évolué de cette façon. Je crois que « pour comprendre le présent et prédire ou influencer l’avenir, nous devons connaître le passé ». Ou comme certains l'ont suggéré, hum chronologie samajhna chahiye ! Passons donc en revue l’évolution de la technologie Web et des navigateurs, en la décomposant en quatre phases simplifiées pour plus de clarté. À la fin de ce voyage, vous comprendrez non seulement comment les technologies Web ont évolué, mais également ce qui se passe sous le capot, pourquoi ces changements se sont produits et ce qu'ils signifient pour l'avenir du Web.

Remarque : Il ne s'agit pas de délais exacts mais plutôt de phases simplifiées pour aider à la compréhension.

Phase zéro : le Web préhistorique

Remontons en arrière avant les années 1980

Imaginez un groupe de chercheurs se précipitant dans les universités américaines, installant des câbles physiques entre des ordinateurs pour transférer ou partager des données. Ces pionniers de la technologie ont établi des protocoles tels que FTP (File Transfer Protocol) et SMTP (Simple Mail Transfer Protocol) pour partager des fichiers et envoyer des e-mails — principalement sur leurs expériences révolutionnaires et peut-être sur des potins occasionnels au bureau. Il y avait des serveurs auxquels nous pouvions nous connecter via un client distant et stocker ou récupérer des fichiers sur le disque à l'aide de commandes écrites.

C'était bien pour de petites quantités de données, mais à mesure que les données augmentaient de plus en plus vite, trouver des informations spécifiques est devenu un véritable casse-tête. Pour récupérer des données, il fallait connaître les chemins exacts, les adresses des serveurs et peut-être faire une petite danse pour apaiser les dieux de l'informatique. Des informations précieuses risquaient d'être perdues dans le remaniement numérique, éparpillées sur les serveurs comme des chaussettes disparaissant dans un tourbillon de blanchisserie.

Première phase : la naissance du Web

Entrez la fin des années 1980 et le début des années 1990

Un brillant Britannique nommé Sir Tim Berners-Lee est arrivé. Il a rédigé une proposition intitulée Gestion de l'information : une proposition. Dans lequel il parlait de l'utilisation de systèmes de texte non linéaires appelés « hypertexte », c'est-à-dire un texte qui inclut les liens vers les informations pertinentes connectées comme une toile d'araignée géante. Ainsi, la navigation et l'exploration des données associées sont plus faciles et la perte d'informations sera minimisée !

Dans cette proposition, il a également fait référence aux ordinateurs interconnectés sous le nom de « Web ». Et c’est ainsi que le World Wide Web est né ! Il ne s’est pas arrêté là ; il a ensuite inventé le protocole de transfert hypertexte (HTTP), développé le premier navigateur, joliment nommé WorldWideWeb (rebaptisé plus tard Nexus), le premier serveur Web HTTP et le premier site Web. Parlez de dépassement de soi !

• HTTP (HyperText Transfer Protocol) : Un ensemble de règles, de syntaxe et de sémantique utilisé pour le transfert d'informations entre un client (par exemple, votre navigateur Web) et un serveur Web (le ordinateur distant hébergeant le site Internet). Si vous vous interrogez sur le nom, sachez qu’au départ, il était uniquement destiné au transfert de fichiers HTML. Mais il a évolué pour prendre en charge le transfert de tous types de données dans les versions ultérieures, après l'introduction des en-têtes, notamment l'en-tête Content-Type.
  
  

• Serveur Web HTTP : Un ordinateur capable de comprendre ce protocole HTTP. La tâche principale est d'analyser la demande et de fournir la réponse demandée, à ce stade, principalement des fichiers HTML, CSS, JPG statiques.

C'est à ce moment-là que le HTML (Hypertext Markup Language) entre en jeu, combinant l'idée de l'hypertexte avec le SGML (Standard Generalized Markup Language), qui était ensuite utilisé pour le formatage des documents. La première version de HTML était assez basique  : elle prenait en charge les titres, les paragraphes, les listes et les liens. Pas de polices fantaisistes ni d'animations flashy — juste l'essentiel.

Pendant les premières années, le Web était comme un club exclusif pour les chercheurs et les universitaires. Ensuite, des gens intelligents ont développé un navigateur appelé Mosaic, qui pouvait afficher des images. Oui, des images ! Cela a rendu le web plus accessible au grand public car, avouons-le, une image vaut mille lignes (mais pas d’image dans ce blog ?) !

Sous le capot du navigateur

Alors, voyons ce qui se passait dans ces navigateurs avec des capacités juste au-dessus

Interface utilisateur : Chaque navigateur avait une barre de navigation en haut où tous vos onglets ouverts (ou fenêtres à l'époque) étaient visibles. En dessous se trouvait la barre d’adresse dans laquelle vous saisissiez l’adresse du site Web. En dessous se trouve l'endroit (fenêtre) où le contenu du site Web que vous avez entré sera affiché. N'oubliez pas que c'était avant les moteurs de recherche, donc si vous ne connaissiez pas l'adresse exacte, vous n'aviez pas de chance — un peu comme essayer de trouver un endroit sans GPS ni carte.

Récupération de données : Lorsque vous entrez une adresse de site Web, le module réseau du navigateur récupère les données en effectuant des tâches telles que la résolution DNS et en établissant une connexion sécurisée avec le serveur pour démarrer la communication. Le navigateur recevrait alors des données sous forme de HTML du serveur.

Moteur de rendu : Le moteur de rendu commencerait à analyser le HTML. S'il rencontrait des balises nécessitant des ressources supplémentaires, telles que des images () ou des styles (

Ensuite, il construirait une arborescence DOM (Document Object Model) à partir du HTML, où chaque balise deviendrait un nœud dans l'arborescence. Après avoir récupéré et analysé le CSS, il construirait un modèle d'objet CSS (CSSOM). Ces deux modèles ont été combinés pour créer l'arbre de rendu, qui sera utilisé pour déterminer ce qu'il faut afficher et comment l'afficher.

• Mise en page et peinture : Vient ensuite la phase de mise en page, où le moteur de rendu calcule la taille et la position de chaque élément sur la page. En partant de la balise relative à la fenêtre (la zone visible de la page Web), il se frayera un chemin à travers l'arbre de rendu. Enfin, lors de la phase de peinture, le moteur de rendu communique avec l'API de rendu du système d'exploitation respectif pour tout dessiner à l'écran.

Vivre avec des limites

À la fin de cette phase, les utilisateurs pouvaient consulter des sites Web statiques et naviguer dans les pages. Les formulaires permettaient des interactions utilisateur de base telles que la saisie de texte et le clic sur des boutons, et ces données de formulaire étaient généralement transférées par courrier électronique aux développeurs. Mais voici le problème : il n’existait aucun moyen de modifier le contenu de manière dynamique en fonction des interactions des utilisateurs. Les utilisateurs pouvaient uniquement cliquer et naviguer entre les liens fournis.

Besoin de mettre à jour quelque chose ? Récupérez à nouveau le tout nouveau code HTML sur le serveur. Vous souhaitez afficher un contenu différent pour différents utilisateurs ? Désolé, cela n'arrive pas. Vous ne pouviez saupoudrer de logique de programmation — pas de boucles, pas de conditions, rien. Si vous vouliez un menu de navigation sur plusieurs pages, il faudrait copier et coller le même code partout.

Deuxième phase : l'essor des scripts côté serveur

Avançons maintenant rapidement jusqu’au milieu et à la fin des années 1990

Les développeurs ont commencé à réfléchir : « Et si nous pouvions mélanger des langages de programmation avec du HTML pour ajouter un peu de logique et nous faciliter la vie ? » Cela a conduit à l’avènement des scripts côté serveur. Des langages comme Java, PHP et Python ont été intégrés au HTML, permettant aux développeurs d'écrire du code capable de traiter des données, de prendre des décisions et de générer du HTML de manière dynamique. Au lieu de servir des fichiers HTML statiques, le serveur peut désormais adapter le contenu à chaque utilisateur.

Comment cela a-t-il changé les choses ?

Du point de vue du navigateur : Le navigateur récupérait et restituait toujours le HTML, mais le contenu qu'il recevait était plus dynamique. Les formulaires sont devenus plus puissants, capables d'envoyer des données aux points de terminaison du serveur à l'aide de requêtes POST.

• Caching et Cookies : La mise en cache est devenue plus sophistiquée sur les navigateurs. Ils stockaient localement des ressources telles que des images et des feuilles de style, réduisant ainsi le besoin de les récupérer à plusieurs reprises. Des cookies ont été introduits pour maintenir l'état sur le protocole HTTP sans état. Ils permettaient aux serveurs de stocker de petites données côté client, qui étaient renvoyées avec les requêtes ultérieures. Cela était crucial pour des choses comme le maintien des sessions, les préférences des utilisateurs, le maintien des utilisateurs connectés — afin que vous n'ayez pas à saisir votre mot de passe à chaque fois que vous clignez des yeux.

Côté serveur : Les serveurs sont devenus plus occupés. Avant cela, nous n'avions que des serveurs Web, qui servaient des fichiers statiques. Mais à ce stade, quelques éléments supplémentaires ont été introduits comme le serveur d'applications, le serveur de base de données (qui peut stocker les catalogues de produits de données utilisateur, etc.), etc. Ils géraient désormais des scripts capables de traiter les entrées de l'utilisateur, d'interagir avec les bases de données et de générer du HTML personnalisé. . C’est à cette époque que le commerce électronique commence à fleurir. Des entreprises comme Amazon et eBay pourraient afficher dynamiquement des produits en fonction des recherches, des préférences et des comportements des utilisateurs.

• Serveur d'applications : Le serveur Web ne peut par nature exécuter aucun script, donc pour faire ce travail, des serveurs d'applications ont été introduits. Fondamentalement, un serveur d'applications se trouve derrière le serveur Web. Chaque fois qu'une demande arrive, le serveur Web vérifie si elle doit être transmise au serveur d'applications en fonction de la configuration et envoie la demande au serveur d'applications. Le serveur d'applications traite ensuite la demande, exécute le script et produit un fichier HTML, qui est ensuite transféré au serveur Web pour servir le client. Le serveur Web agit donc en quelque sorte comme un proxy inverse pour le serveur d'applications.

Un exemple avec JSP (JavaServer Pages)

À l'époque où j'étais à l'université, je me souviens avoir bricolé un vieux projet JSP. Ces scripts suivent généralement une structure commune : ils sont constitués de HTML et, partout où une logique doit être ajoutée, elle est intégrée à l'aide d'identifiants spéciaux tels que (fermer) dans le cas de JSP. Voici un exemple simple :

greet.jsp

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

Dans cet exemple, lorsqu'un utilisateur soumet son nom, le serveur reçoit la requête HTTP contenant les données du formulaire, traite les informations et génère dynamiquement un message d'accueil personnalisé pour l'utilisateur. Fini les « Hello, World ! » génériques. Maintenant, c'est "Bonjour, [Votre nom] !" — boost instantané de l'ego.

Génération de contenu dynamique : Au lieu de coder en dur des listes ou du contenu, vous pouvez récupérer des données à partir d'une base de données et les parcourir en boucle ou les utiliser pour générer des éléments HTML. Par exemple, afficher une liste de fruits :

Cela pourrait facilement être étendu à la récupération de fruits à partir d'une base de données, rendant votre contenu plus dynamique et plus frais !

Les nouveaux défis

Bien que les scripts côté serveur aient changé la donne, cela n'a pas été sans défis.

Actualisation complète de la page : Chaque fois que vous interagissez avec le serveur, comme en soumettant un formulaire ou en cliquant sur un lien, la page entière devait être rechargée car toute logique ne pouvait être exécutée que sur le serveur d'application, ce qui générait nouveau HTML. Les utilisateurs devaient attendre la réponse du serveur avant de voir les résultats de leurs actions. Cela a provoqué une expérience utilisateur pas si géniale.

Charge du serveur : les serveurs devaient gérer tout le traitement, de l'exécution des scripts à l'interrogation des bases de données. À mesure que les sites Web devenaient plus populaires, les serveurs étaient confrontés à une charge accrue, ce qui entraînait une augmentation du temps de chargement et des retards pour les utilisateurs. Nous savons que la patience est une vertu, mais ce n’est pas celle que les utilisateurs possèdent en abondance. Alors que les navigateurs et les ordinateurs côté client deviennent de plus en plus performants, la question se pose : pourquoi ne peuvent-ils pas prendre en charge une partie de la charge de travail pour améliorer les performances et la réactivité ?

Troisième phase : la révolution côté client

Entrez à une époque où les développeurs en avaient assez de ces rechargements de pleine page. Il était temps de changer, et ce changement s'est manifesté sous la forme de scripts côté client ou de rendu côté client (CSR).

JavaScript, qui avait été discrètement introduit par Netscape en 1995, commençait désormais à attirer l'attention. Il permettait aux développeurs d’exécuter du code directement dans le navigateur de l’utilisateur, ce qui signifie que toutes les interactions ne devaient pas nécessairement impliquer le serveur. Cela a conduit à des expériences Web beaucoup plus fluides et plus réactives. Plusieurs facteurs principaux ont été impliqués dans cette révolution :

Capacités accrues du navigateur : Au fil du temps, les appareils des utilisateurs sont devenus de plus en plus puissants — et les navigateurs aussi. Il est donc devenu évident de décharger une partie du travail du serveur vers le navigateur, ce qui a considérablement amélioré l'expérience utilisateur. Les navigateurs n'étaient plus de simples visualiseurs de documents passifs ; ils ont évolué vers des plates-formes capables d'exécuter des applications complexes.

API Web : Pour exploiter cette nouvelle puissance, les navigateurs ont commencé à proposer des API Web  – un ensemble de fonctions qui permettaient à JavaScript d'interagir avec les capacités du navigateur. Voici quelques API Web principales qui ont aidé JavaScript à évoluer :

• L'API DOM a fourni un moyen d'interagir et de manipuler dynamiquement la structure et le contenu des pages Web dans le navigateur. Il a également permis d'ajouter des écouteurs d'événements tels que le clic, le déplacement de la souris, etc., sur n'importe quel élément, permettant aux développeurs de répondre instantanément aux interactions des utilisateurs. Vous souhaitez ajouter un nouveau paragraphe lorsqu'un utilisateur clique sur un bouton ? Ne générez plus l’intégralité du code HTML, c’est simple comme bonjour.

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

• XMLHttpRequest a changé la donne. Il a permis aux développeurs d'effectuer des requêtes HTTP asynchrones non bloquantes directement à partir du code exécuté dans le navigateur et de récupérer les données du serveur. À l'époque, les données étaient généralement transférées au format XML — d'où le nom — mais JSON a ensuite pris le relais car il est moins verbeux et plus facile à utiliser. Finalement, l'API fetch est arrivée, offrant des fonctionnalités avancées et une syntaxe plus claire.

AJAX (JavaScript asynchrone et XML) : AJAX a été l'une des technologies essentielles à l'origine de cette révolution. Il explique comment les pages Web peuvent communiquer avec les serveurs en arrière-plan pour obtenir les données requises et mettre à jour le contenu directement dans les navigateurs à l'aide de l'API DOM et de XMLHttpRequest, sans nécessiter un rechargement complet de la page. Soudain, le Web a commencé à paraître… interactif ! Encore une fois, le nom vient de XML, qui était utilisé pour le transfert de données.

Comment cela a-t-il changé les choses ?

Du point de vue du navigateur : Un nouveau <script> La balise a été introduite en HTML, permettant aux développeurs d'ajouter du code JavaScript directement en HTML. Lorsque le moteur de rendu du navigateur analyse le code HTML et rencontre un message <script> tag, il récupérerait et exécuterait le script (l'ordre dépend des accessoires asynchrones et différés), permettant un contenu dynamique et des fonctionnalités interactives.</script>

• Moteur JavaScript : Pour évaluer ces scripts, des moteurs JavaScript ont été introduits dans les navigateurs. Les premiers moteurs étaient relativement simples et plus lents, mais les moteurs modernes comme le V8 de Google et le SpiderMonkey de Mozilla ont considérablement évolué, permettant une logique côté client plus complexe.
  
  

• Event Loop : JavaScript a été conçu comme un langage de script monothread pour garder le langage simple et léger. Ce choix de conception a également été influencé par des facteurs tels que les ressources informatiques limitées et le maintien du DOM (Document Object Model) thread-safe, évitant ainsi les conditions de concurrence lors de la manipulation du DOM.
  
  

  Étant donné que toutes les tâches d'exécution de script et de rendu partagent un seul thread, JavaScript avait besoin d'un moyen de gérer les opérations asynchrones sans bloquer le thread principal. Pour y parvenir, JavaScript s'appuie sur le concept de la Event Loop.
  
  

  Voyons comment cela fonctionne en interne :
  
  

  Lorsque le moteur de rendu analyse le code HTML et rencontre un message <script> tag, il récupère le script et le transmet au moteur JavaScript. Le moteur JavaScript commence à exécuter le script en poussant les contextes d'exécution sur la pile d'appels. <br><br> </script>

  JavaScript s'appuie sur les API Web fournies par le navigateur pour gérer les tâches asynchrones sans bloquer le thread principal. Il s'agit notamment des API pour les minuteries (setTimeout, setInterval), les requêtes HTTP (fetch, XMLHttpRequest), les événements DOM, etc. Lorsqu'une opération asynchrone est invoquée, le moteur JavaScript la transmet à l'API Web, ainsi qu'une fonction de rappel, et continue d'exécuter le reste du code. Une fois cette tâche asynchrone terminée, les navigateurs envoient le rappel vers la file d'attente des tâches respective (file d'attente Microtask ou file d'attente Macrotask).
  
  

  Voici comment la boucle d'événements gère ces files d'attente ainsi que le rendu
  
  

  1. File d'attente des microtâches : Les promesses, les rappels de MutationObserver, etc. entrent ici. Cette file d'attente a la priorité la plus élevée. Une fois la pile d'appels vide, la boucle d'événements vérifie la file d'attente des microtâches. Il traite toutes microtâches de la file d'attente, les unes après les autres, en les poussant sur la pile d'appels pour exécution. Si des microtâches ajoutent de nouvelles microtâches à la file d’attente, celles-ci sont également traitées avant de passer à autre chose.
  
  

  2. Rendu : Une fois la file d'attente des microtâches vide, le moteur de rendu peut reprendre le thread principal et effectuer le rendu si nécessaire. Cela inclut la mise à jour de l'interface utilisateur pour refléter toutes les modifications DOM apportées lors de l'exécution du script et du traitement des microtâches. Ceci est effectué en fonction de la fréquence d'images de l'appareil, une fois par image, pour optimiser les performances.
  
  

  3 . File d'attente de macrotâches : Les rappels de setTimeout, setInterval, les événements DOM, les événements d'E/S, etc. entrent ici. Cette file d'attente a la priorité la plus basse. La boucle d'événements extrait une tâche de cette file d'attente et l'exécute. Après avoir exécuté cette tâche, il traite toutes les microtâches et le rendu avant d'exécuter la macrotâche suivante.
  
  

  [Appeler la pile vide] → [Traiter toutes les microtâches] → [Rendu si nécessaire] → [Exécuter une macrotâche] → Répéter

Côté serveur : Le côté client gérant davantage l'interface utilisateur et les interactions utilisateur, les serveurs ont commencé à changer d'orientation. Les serveurs ont commencé à fournir des données et une logique métier via des API. Ils ont évolué du service de fichiers HTML statiques pour devenir de puissants moteurs capables de traiter les requêtes, d'interagir avec les bases de données et d'effectuer des calculs complexes pour fournir des données. Au lieu de servir uniquement pour les navigateurs, ils ont commencé à servir un large éventail de clients (applications mobiles ou de bureau, autres serveurs, etc.).

REST : Le concept de REST est devenu populaire. REST (Representational State Transfer) est un style d'architecture qui fournit un ensemble de lignes directrices et de contraintes pour la conception de services Web. Pour résumer, chaque ressource est identifiée de manière unique par une URL et des méthodes HTTP standard telles que GET, POST, PUT et DELETE sont utilisées pour manipuler ces ressources dans des interactions client-serveur sans état. Cela a permis aux serveurs d'être simples, évolutifs et efficaces.

À mesure que les applications devenaient plus populaires, les serveurs devaient gérer davantage de traitement de données et de logique métier. Les serveurs d'applications et les serveurs de bases de données sont nécessaires pour traiter les données de manière très efficace. Les serveurs ont dû mettre en œuvre quelques nouvelles techniques pour faire face à cette lourde charge, telles que la mise en cache côté serveur, l'équilibrage et l'évolutivité de la charge, l'architecture des microservices, etc.

JavaScript EveryWhere : Avec l'introduction de NodeJS (un environnement d'exécution JavaScript), Javascript peut désormais être exécuté en dehors des navigateurs, apportant le concept de « JavaScript EveryWhere » (côté client et côté serveur). ). Parallèlement, npm (node ​​package manager) a été introduit, ce qui a aidé les développeurs à partager facilement du code JavaScript. Avec ceux-ci, l'écosystème JS s'est développé rapidement, fournissant tous les outils nécessaires (frameworks, bundlers, compilateurs, transpilateurs, etc.) requis pour le projet.

Applications à page unique : Avec JavaScript effectuant désormais la création et la manipulation de DOM côté client, il était nécessaire de disposer de frameworks pour créer des applications complexes plus efficacement. Entrez dans des frameworks comme Angular, React, etc. C'est le summum des scripts côté client. Fondamentalement, dans un SPA, un seul petit fichier HTML est récupéré du serveur, qui consiste en un Javascript regroupé de l'application entière dans un <script> étiqueter. Et ce script s'occupe lui-même de toutes les interactions utilisateur et des mises à jour de l'interface utilisateur, y compris le rendu initial.</script>

Encore des défis

Même si cette phase a résolu les défis de la phase précédente, elle a créé de nouveaux défis tels que :

• Temps de chargement initiaux plus longs : Les SPA signifiaient souvent de gros ensembles JavaScript initiaux, ce qui pouvait ralentir les temps de chargement initiaux — en particulier sur les réseaux ou les appareils plus lents. Même si les utilisateurs n'en veulent que quelques parties, ils doivent obtenir le script dans son intégralité — comme télécharger le film en entier juste pour regarder la bande-annonce. Les développeurs ont dû utiliser des techniques telles que le fractionnement de code, le chargement paresseux, le tremblement d'arbre, la minification, etc. pour optimiser cela.
  
  

• Préoccupations liées au référencement : Comme la plupart du contenu est généré dynamiquement, les moteurs de recherche ont du mal à indexer ces sites Web. Il est difficile de se faire remarquer lorsque le robot d’exploration de Google ne peut pas voir votre site. Des techniques telles que le rendu côté serveur (SSR) et le pré-rendu peuvent résoudre ces problèmes.
  
  

• Fatigue JavaScript : Avec l'apparition de nouveaux frameworks, outils et bibliothèques chaque jour, les développeurs en ont eu assez d'essayer de rattraper leur retard. Suivre les dernières tendances, c'est comme courir sur un tapis roulant sans fin ! Et aussi choisir une bonne pile est devenu très difficile avec autant de choix.
  
  

• Plus rapide, mais plus lent : Les performances côté serveur et côté client ont augmenté, mais pas autant que les développeurs voudraient impressionner les utilisateurs. De plus, même si les navigateurs sont rapides et performants, ils ne sont pas aussi rapides ni aussi performants que les applications natives. Par exemple, vous ne pouvez pas créer d'applications complexes comme des jeux ou des éditeurs vidéo.
  
  

Quatrième phase : le Web moderne et au-delà

Bienvenue dans l'ère moderne du développement Web  — une époque où le Web est plus dynamique, puissant et centré sur l'utilisateur que jamais. Discutons de quelques choses existantes qui se produisent actuellement et qui pourraient résoudre les défis de la phase précédente.

Il n’existe pas de solution unique de rendu parfait

Après la phase précédente, nous avons découvert qu'il n'existe pas une seule stratégie de rendu parfaite pour tout le monde. Nous devons choisir une stratégie de rendu correcte, parfois hybride, en fonction de nos exigences et contraintes. Voici quelques-unes de ces stratégies de rendu

1. Génération de site statique (SSG) : Contrairement au rendu côté client (CSR), où JavaScript crée du HTML dans le navigateur de l'utilisateur, SSG génère l'intégralité du fichier HTML au moment de la construction et sert ces éléments statiques pré-générés. Fichiers HTML, CSS, JS aux utilisateurs sur demande. Nous pouvons même utiliser un CDN pour accélérer la réponse.

   Il résout des problèmes tels que des temps de chargement initiaux plus longs et des problèmes de référencement. Il dispose également d’une première peinture de contenu très rapide. Nous n'avons pas à nous soucier beaucoup des problèmes de mise à l'échelle, car les fichiers statiques peuvent être facilement servis via des CDN. Nous pouvons choisir cette stratégie si la plupart du contenu de notre site Web est statique. Cependant, si le contenu est plus dynamique et spécifique à l’utilisateur, cela ne fonctionnera pas bien. Dans ces cas, nous pouvons choisir une approche hybride utilisant SSG et CSR avec hydratation comme expliqué ci-dessous. Vous pouvez également consulter le JAMStack qui explique plus en détail l'utilisation de SSG avec des API sans serveur et des fonctions Edge.

2. Rendu côté serveur (SSR) : C'est un peu similaire à la deuxième phase, mais ici, la logique métier est séparée du script côté client. Fondamentalement, au lieu que les navigateurs exécutent le script et génèrent du HTML, nous exécutons les scripts sur le serveur pour générer du HTML et le transmettons au navigateur à chaque demande de l'utilisateur.

   Encore une fois, même si cela résout des problèmes tels que des temps de chargement initiaux plus longs et des problèmes de référencement, cela augmente la charge du serveur. De plus, la plupart d'entre nous ne souhaitent pas que la page se recharge à chaque fois que l'utilisateur interagit, nous devons donc opter pour une approche hybride incluant la RSE et l'hydratation.

Hydratation : Fondamentalement, nous servons d'abord le fichier HTML statique pour le rendu et ajoutons l'interactivité de l'utilisateur en exécutant le JavaScript après le rendu initial. Ce processus de conversion de pages Web statiques en pages Web dynamiques est appelé Hydratation. Après hydratation, l'application se comporte de manière similaire à une application CSR.

L'hydratation pose quelques problèmes, les utilisateurs ne peuvent pas interagir avec le contenu dès qu'ils le voient. Ils doivent attendre que ce script soit téléchargé et exécuté, ce qui ajoute encore une fois le même temps système similaire à CSR. Pour atténuer cela, il existe de nouvelles approches d'hydratation comme l'hydratation progressive et l'hydratation partielle, mais celles-ci sont difficiles à mettre en œuvre.

Les frameworks modernes comme Next.js, Nuxt.js, Gatsby et React fournissent ces diverses stratégies de rendu, ainsi que de nouvelles techniques telles que la régénération statique incrémentielle et le Streaming SSR.

---

Assez épuisant, n'est-ce pas ! Ouais, je sais, mais c'est presque fini. Il existe également de nombreuses API Web existantes qui ont été ajoutées ou proposées. Bien que nous ne puissions pas tous les couvrir, consultez quelques API notables, notamment Web Workers, IndexedDB et Shared Storage.

Mais voici les deux principales technologies Web qui peuvent nous enthousiasmer

WebAssembly (Wasm)

Même si les moteurs JavaScript modernes s'efforcent de rendre JS plus rapide, le principal goulot d'étranglement réside dans le fait que JS est un langage typé dynamiquement et non compilé. Cela signifie que nous ne pouvons pas compter sur JS pour des calculs très gourmands en performances. C'est là qu'intervient WebAssembly. WebAssembly est un format d'instruction binaire généré par le code écrit dans des langages comme C, C et Rust, etc., qui peut s'exécuter à une vitesse quasi native sur tous les navigateurs modernes sans plugins.

Wasm fonctionne avec JavaScript, permettant d'appeler des fonctions entre elles. Il ne prend pas encore en charge la manipulation directe du DOM ni l'utilisation d'autres API Web, mais le développement en cours vise à ajouter cette fonctionnalité prochainement. Wasm peut être utilisé pour toutes les applications Web exigeantes en performances, telles que les jeux, le traitement d'images, le montage vidéo, etc.

Applications Web progressives (PWA)

Avec ce vaste écosystème Web, pourquoi ne pouvons-nous pas créer une application Web de type natif ? Les applications Web progressives sont des applications Web qui peuvent être installées directement à partir des navigateurs et fonctionnent de manière similaire aux applications natives, fournissant une assistance hors ligne, des notifications push, etc. Et elles offrent des expériences rapides, attrayantes et fiables sur toutes les plates-formes avec une seule base de code.

Un composant clé des PWA est le Service Worker , qui exécute les scripts en arrière-plan séparément du thread principal du navigateur. Il peut servir de proxy entre l'application Web, le navigateur et le serveur. Les Service Workers peuvent contrôler la façon dont les demandes sont traitées et retarder certaines actions jusqu'à ce que l'utilisateur dispose d'une connectivité stable. Cela nous permet de mettre en cache les ressources à l'aide de l'API Cache, afin que le contenu puisse être diffusé même lorsque l'appareil est hors ligne ou sur un réseau lent, puis synchronisé avec le serveur une fois de nouveau en ligne.

Cependant, toutes les fonctionnalités ne sont pas encore prises en charge de manière uniforme sur tous les navigateurs. Et la création de PWA nécessite une planification minutieuse des stratégies de mise en cache et du comportement hors ligne. De plus, les PWA n'ont peut-être pas encore accès à toutes les fonctionnalités de l'appareil par rapport aux applications natives, mais cela est en expansion.

---

Le Web n'est pas encore parfait, mais à mesure que nous regardons vers l'avenir, les frontières entre les applications Web, natives et de bureau continuent de s'estomper. Avec autant de technologies émergentes, les possibilités sont illimitées.

Cela nous amène à la fin de notre blog. S'il vous plaît laissez-moi savoir si je me trompe sur quelque chose ou si j'ai raté quelque chose. Continuez à explorer et continuez à apprendre. Au revoir !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!