Dans cette première vidéo de la série, le formateur introduit le contexte du développement web moderne en comparant le rendu côté serveur (SSR) et le rendu côté client (CSR). Il détaille les avantages et inconvénients de chaque approche, puis présente React comme une bibliothèque JavaScript open‑source largement adoptée (plus de 45 % des sites en 2024). Il explique pourquoi React est considéré comme « unopinionated », décrit ses concepts fondamentaux (Virtual DOM, composants, hooks, props) et mentionne son extension vers le mobile via React Native. Le formateur introduit ensuite Next.js, un framework qui enrichit React avec le SSR et d’autres optimisations de performance, tout en soulignant la nécessité de maîtriser les fonctionnalités modernes de JavaScript (ES6, fonctions fléchées, promesses, async/await). Enfin, il indique une ressource de playlist JavaScript pour les apprenants et conclut en invitant à la prochaine vidéo.
Chapters
Bonjour à tous et bienvenue dans cette nouvelle série de cours qui porte sur la bibliothèque React. Pour la plupart d'entre vous qui avez déjà développé des sites ou applications web avec des langages comme PHP, ASP.NET, Ruby ou Python, que ce soit à travers des frameworks qui supportent l'architecture MVC comme Laravel, Ruby on Rails, Django, ou en utilisant la syntaxe de base dite aussi Vanilla, vous générez souvent des vues dans vos applications de manière dynamique. C'est-à-dire qu'après l'exécution du code sur le serveur, du contenu HTML est généré puis transféré au navigateur de l'utilisateur final. C'est ainsi que la page s'affiche englobant tout le contenu requis. En fait, même avec l'environnement d'exécution Node.js, en l'occurrence à travers le framework Express, il est possible de créer des vues directement depuis le serveur notamment à travers les moteurs de template Pug ou EJS. Bien qu'à la base, Express est censé être un framework backend qui ne se soucie pas de la manière avec laquelle la page sera présentée sur le client. Le fait de générer les vues depuis le serveur est connu sous le nom de Server-Side Rendering ou SSR. Autrement dit, l'interface utilisateur est totalement ou majoritairement créée par le serveur de manière dynamique en y intégrant toutes les ressources nécessaires, y compris les informations qui proviennent de la base de données ou d'API distantes. Donc, on imagine que le navigateur ne fait qu'exécuter ce qu'il a reçu du serveur sans qu'il ait vraiment un rôle crucial dans la façon dont le contenu est présenté. En effet, c'est le serveur qui a décidé de cette présentation. Bien entendu, le SSR présente de nombreux avantages que l'on peut résumer dans les points suivants: Chargement initial rapide: en effet, puisque la page est entièrement construite par le serveur, le navigateur l'exécute plus rapidement améliorant ainsi l'expérience utilisateur. En l'occurrence si la connexion de ce dernier est lente. Optimisation pour les moteurs de recherche: là encore, le SSR marque un point, car la page rendue au navigateur peut être optimisée pour le SEO, facilitant ainsi son référencement et son positionnement dans les moteurs de recherche. Du côté du développeur, le SSR s'avère généralement plus facile à manipuler, car il est relativement simple d'incorporer du code HTML et CSS dans la réponse du serveur, ce qui permet de rendre une page complète du premier coup. Néanmoins, le SSR présente aussi quelques inconvénients, notamment: Charge importante sur le serveur. En effet, en plus de chercher et traiter les données qui proviennent généralement de sources comme les bases de données ou les API, le serveur doit aussi s'occuper de la présentation en mettant en page les données traitées afin de servir une page prête à l'affichage au navigateur, ce qui implique une consommation supplémentaire de ressources du serveur. Rechargement exigeant. Si le chargement initial peut être vu comme un avantage surtout vis-à-vis des connexions lentes, le fait de demander une nouvelle page oblige le serveur à refaire le même cycle décrit précédemment, ce qui peut être exigeant en temps de réponse ainsi qu'en bande passante. Interactivité faible: Cela joint les 2 points que l'on vient de voir. En effet, l'utilisateur ressent un manque de fluidité quand il change de page, en cliquant sur un lien par exemple, car la page demandée met un temps important à se charger. Sans parler du fait que dans la plupart des cas, cette dernière est entièrement rechargée, ce qui donne lieu à un scintillement parfois désagréable. Couplage étroit: Ça signifie que le SSR intègre en même temps le processus Front End et Back End, ce qui rend la maintenance de l'application difficile durant son cycle de vie, car il y a une forte dépendance entre les éléments du Front et du Back, ce qui peut exiger beaucoup d'ajustements suite à une modification d'une partie du code. Sans parler de la réduction de la modularité et de réutilisabilité des composants de l'application, d'autant plus si on souhaite créer une application mobile qui requiert les mêmes données et les mêmes traitements que l'application web. Une bonne maîtrise de la part du développeur, qui doit prendre en main un grand nombre de technologies comme le HTML et CSS avancés, le JavaScript, les bases de données, un ou plusieurs langages CGI comme PHP ou Perl, sans parler d'autres aspects avancés comme les tests ou la sécurité. À l'opposé du Server Side Rendering, il y a le Client Side Rendering ou CSR qui quant à lui consiste à construire la page dynamiquement par le navigateur, généralement à l'aide du JavaScript après avoir reçu un contenu minimal du serveur. En d'autres termes, après la réception de la requête du client, le serveur se charge de présenter les données voulues, soit en les cherchant dans une base de données ou une API, ou en les générant dynamiquement en suivant une certaine logique. Ensuite, il formate ces données-là selon une structure commune comme XML ou JSON que l'on envoie ensuite au navigateur. À partir de ce moment, il incombe au navigateur de présenter les données qu'il a reçues en créant dynamiquement l'UI ou User Interface à l'aide du JavaScript. Bien entendu, le code JavaScript qui assure la création des vues est chargé la toute première fois que le navigateur se connecte au serveur qui héberge le site ou l'application web. Là, on voit bien que le Front End et le Back End sont bien séparés et se chargent chacun d'exécuter un traitement dans un périmètre bien défini. Donc, le CSR présente de nombreux avantages comme l'interactivité avancée, le chargement rapide de nouveaux contenus, sans parler de la page qui n'est plus obligée de se recharger entièrement, ce qui améliore l'expérience utilisateur. Néanmoins, le CSR est quand même truffé de quelques inconvénients, notamment le chargement initial lent. En effet, puisque le navigateur se charge de reconstruire les vues de l'application à l'aide du code JavaScript, alors il doit importer tout ce code-là lors du premier chargement de l'application. Ce qui explique parfois l'impression de blocage qui marque la première page des sites ou applications web que vous visitez, mais après tout redevient très fluide. Il se peut également que les développeurs habitués au Server Side Rendering trouvent le Client Side Rendering plus contraignant, car les éléments du backend et du frontend sont séparés et gérés différemment. Or, le CSR permet de séparer les tâches, ce qui facilite le développement de grandes applications scalables en impliquant de nombreux développeurs. Chacun spécialisé dans un domaine particulier, autrement dit le frontend et le backend. Il existe plusieurs bibliothèques et frameworks JavaScript qui permettent de monter une application web en CSR, notamment React, Angular et Vue.js. React, que certains développeurs appellent React.js pour éviter toute confusion avec le framework React Native destiné à la création des applications mobiles, est une bibliothèque JavaScript open source créée au sein de Facebook ou Meta actuellement, et rendu officiel en 2013. À la base, React a été développé pour mieux gérer le fil d'actualité sur Facebook, avant qu'il devienne un élément clé dans d'autres produits de l'entreprise. React est l'une des bibliothèques frontend les plus utilisées dans le monde, aux côtés d'Angular et Vue.js. En effet, selon une enquête menée en 2024, React est utilisé dans plus de 45% de sites web à travers le monde. Et un grand nombre de développeurs qui ont été interrogés ont manifesté une grande satisfaction à son égard. Si React est aussi populaire, c'est généralement en raison de sa simplicité et sa grande flexibilité. En effet, React fait partie des bibliothèques et frameworks unopinionated. Un framework unopinionated ou sans opinion est un framework qui offre une grande flexibilité et liberté aux développeurs et n'impose pas de conventions strictes et rigides, comme la manière de structurer et organiser un projet. D'ailleurs, React est vu comme une bibliothèque et non pas un framework, car il n'impose pas de conventions ou structures strictes. En plus, il offre un minimum de modules par défaut afin de monter une interface utilisateur. Néanmoins, le développeur peut toujours télécharger et importer au choix des modules supplémentaires pour gérer d'autres aspects du projet, comme on le verra plus loin dans ce cours. Un autre avantage de taille en faveur de React consiste dans sa possibilité de s'en servir dans React Native qui est un framework destiné à la création des applications mobiles hybrides. Ce qui signifie que la maîtrise de React implique systématiquement la possibilité de créer des applications mobiles avec du code natif pour Android et iOS en même temps. React est un écosystème riche et qui jouit de ses propres mécanismes comme le Virtual DOM, les composants, les hooks, les props, ainsi que de nombreuses autres fonctionnalités qui lui sont caractéristiques. Il est possible de coder en React en utilisant du JavaScript ou TypeScript qui est une sorte de JavaScript typé statiquement. Depuis un moment, un framework nommé Next.js a fait son apparition. Il s'agit d'un framework React, c'est-à-dire qu'il étend les fonctionnalités de React en ajoutant de nouvelles options, notamment le Server Side Rendering. En effet, bien que le SSR soit une technique qui présente quelques inconvénients comme on l'a vu au début de cette vidéo, il est quand même apprécié dans certains contextes. C'est pour cette raison qu'il y a possibilité de l'utiliser en Next.js. Il y a aussi d'autres aspects que Next.js apporte afin d'améliorer les performances et l'expérience utilisateur. Cela dit, pour utiliser Next.js, il faut avoir une certaine maîtrise de React avant car il en constitue l'essence. Il est évident que pour coder en React, il faut avoir une bonne maîtrise du langage JavaScript, notamment les aspects modernes du langage apportés en ES6 comme la notion de fonction fléchée, les callbacks, promesses et fonctions asynchrones, etc. Si ce n'est pas le cas, une maîtrise moyenne de JavaScript peut être suffisante, car comme d'habitude, je vais essayer d'avancer progressivement dans le cours afin que tout le monde puisse trouver son rythme. Je vous mets en description le lien vers ma playlist de JavaScript si vous voulez apprendre ce langage ou seulement vous mettre à niveau. Merci pour votre attention et à la vidéo prochaine.
