Aller au contenu
Accueil / La révolution du JavaScript

La révolution du JavaScript

revolutionJS

Pendant longtemps (à l’époque de jQuery), la référence du JavaScript a été l’ES5, la version 5 de l’ECMAScript, sortie en 2009.

Puis en 2015, tout à changé.

Au sommaire :

1- JavaScript ES6

En juin 2015 en effet, une nouvelle version de JavaScript est sortie : l’ES6. Cette version permettait de combler les lacunes des versions précédentes et proposait de nouvelles règles qui allaient devoir être implémentées par les navigateurs, ce qui a pris quelques années.

Le nouveau standard ES6 / ES2015 a ajouté de nombreux nouveaux outils à JavaScript, comme la syntaxe des classes, l’import/export de modules, une portée de bloc pour les variables, etc. Cela rapproche donc JavaScript d’autres langages comme Java, C# ou PHP. Depuis lors, la mise à jour du standard JavaScript est devenue annuelle. La version 2022 est donc la ES13.

1.1- Le déplacement de la limite entre back et front

Avec ES6, une partie du back-end s’est alors déplacée vers le front-end. Ou pour le dire autrement, certaines choses qui dépendaient autrefois du serveur relèvent désormais du navigateur. La vidéo ci-dessous explique bien le changement intervenu :

Les deux approches du développement web – La Tech avec Bertrand (8’25 min)

Voir aussi Lior Chamla :

↑ — Revenir au sommaire

1.2- Intégrateur web vs développeur web front

En matière de création de sites web, ce que faisait autrefois l’intégrateur web est donc devenu une toute petite partie de ce que fait aujourd’hui le développeur web front : Intégrateur et dev front end sont devenus deux métiers différents.

Le vrai travail du développeur frontend – Benjamin Code

↑ — Revenir au sommaire

2- Web components et Single Page Applications

L’idée est ainsi de concevoir notre application sous forme de blocs indépendants réutilisables et fonctionnant de manière isolée : Les composants web. Or, on souhaite rendre nos composants réactifs. Lorsque l’état d’un composant change, l’interface de ce dernier doit être capable de changer, indépendamment de ses voisins.

Composants web

Un page web qui est capable de ne mettre à jour que ce qui doit l’être, sans demander au serveur de tout recharger, c’est le principe des Single Page Applications. L’idée est qu’on ne quitte jamais la page d’origine, qui ne se charge qu’une seule fois. Ce sont ses composants qui se mettent à jour automatiquement en fonction de ce qu’on y fait.

Exemples : Facebook, Instagram, Gmail… Mais aussi toutes les plateformes SaaS (Software as a Service) : Google Drive, Office 360… En fait, la plupart des grands sites connus sont passés aux Single Page Applications (SPA) : WhatsApp, Twitter, Reddit, Netflix, AirBnB, Uber, Tesla, Paypal, Ryanair, Alibaba, Nintendo, Baidu, Expedia, Gitlab… et même Gutenberg de WordPress !

↑ — Revenir au sommaire

3- Les API

3.1- Application Programming Interface

API signifie Application Programming Interface (interface de programmation d’application). Pour faire simple : c’est un moyen de communication entre deux logiciels, que ce soit entre différents composants d’une application ou entre deux applications différentes.

Architecture orientée services (SOA) – Web services (WS)
  • l’application mobile qui communique avec le système d’authentification fait en Java,
  • le logiciel en C++ qui communique avec le site vitrine en PHP,
  • le site React JS qui récupère la liste des produits disponibles dans l’application Java,
  • Mais aussi les sites e-commerce qui communiquent avec les banques pour faire des virements bancaires,
  • ou l’appli mobile qui intègre Google maps ou un service météo.
API : comprendre l’essentiel en 4 minutes – Cookie connecté

↑ — Revenir au sommaire

3.2- L’approche API-first en développement web

Dans l’approche API-first, le front-end et le back-end sont totalement séparés. Ainsi, ce sont les API qui font le lien entre les deux.

Exemple d’architecture full JS : Node (back) + React (front), reliés par une API (mindmap de ma composition, cliquez pour agrandir)

↑ — Revenir au sommaire

3.3- Différents types d’API

Il existe différents types d’API pour différents type d’utilisation. Deux interviennent dans le contexte du web :

API REST vs API GraphQL

↑ — Revenir au sommaire

3.4- Back vs front, une nouvelle répartition des rôles

Parmi les parties d’application à relier, il y a donc le front et le back des applications web:

3.4.1- Le développeur back

Le développeur back s’occupe de la logique métier. Il va mettre en place une architecture serveur et une base de données, et créer une ou des API pour y accéder, à destination du développeur front : on dit qu’il expose une API.

Les frameworks qu’il peut utiliser varieront selon le langage back utilisé : Symfony ou Laravel pour PHP, Spring Boot pour Java, NodeJS pour… JavaScript, etc.

Frameworks back pour JS

Exemple de mise en place d’un back avec Express / NodeJS :
https://github.com/Tadkozh/ExpressMusic

3.4.2- Le développeur front

Le développeur front s’occupe de l’expérience utilisateur. Il va mettre en place les composants web et les rendre réactifs en appelant une ou des API créées par le développeur back : on dit qu’il consomme l’API.

Ses frameworks seront tous basés sur JavaScript, éventuellement sur CSS. Les plus répandus sont Angular, React, Vue.js. Il en existe bien d’autres qui ont chacun leurs spécificités, comme Svelte, Astro, Alpine, ou encore Next, Gatsby, etc.

Aujourd’hui les principaux frameworks sont tous capables de fonctionner avec Typescript, une surcouche facultative de JavaScript créé par Microsoft pour le typage des données… et transpilé in fine en JS vanilla. En réalité, que ce soit Node.js, React ou Vue.js, tout l’écosystème JavaScript se met progressivement au Typescript.

JS vs TS

Exemples de mise en images d’API publiques avec React :

✨ Smoothy : https://github.com/Tadkozh/smoothy-P2
✨ Flow : https://github.com/Francescosaverio1989/Flow
✨ Wild Games : https://github.com/Tadkozh/Wild-Games
✨ Mano Mano : https://github.com/Paul-Verdure/team-boulet/tree/main/team-boulet

L’approche API-first, où le front et le back sont totalement séparés, et où les API font le lien entre les deux

↑ — Revenir au sommaire

3.5- JavaScript Object Notation

Dans les sites dynamiques, où les pages sont générées à la volée côté serveur, le HTML et le langage serveur (souvent PHP) sont mélangés dans les fichiers (approche monolithique), et les requêtes HTTP conduisent au (re)chargement de la page entière.

3.5.1- Le format JSON

Avec la révolution des composants web, le front et le back sont nettement séparés. Pour que chaque composant du front accède aux informations qu’il lui faut côté back, une requête HTTP classique client-serveur ne suffit plus. C’est là qu’interviennent les API web, qui vont générer plusieurs requêtes HTTP ciblées, ainsi que d’autres éléments, et renvoyer une réponse, souvent en JSON, un format standard utilisé pour représenter des données structurées de façon semblable aux objets JavaScript, lequel est en train de remplacer le XML. JSON veut en effet dire… JavaScript Object Notation !

Les fichiers JSON, ce sont toujours des objets et des tableaux, imbriqués les uns dans les autres, écrits en JS. Ils servent pour les API, mais aussi pour les bases de données NoSQL. Ci dessus, extrait d’une route dans une API REST
  • En savoir plus : JSON – Grafikart : Article | Vidéo (13 min)

Dans le cas des applications web, les API sont concoctées par le développeur back à destination du développeur front. En réalité il ne les tape pas directement : elles sont générées automatiquement par son framework, par exemple Express, à partir de son code et de sa base de données.

↑ — Revenir au sommaire

3.5.2- Interprétation

Le rôle du développeur front est alors de mettre cette API en scène pour les utilisateurs finaux. Ci-dessous, une interprétation possible du fichier JSON précédent, sur la base d’une maquette et de userstories :

Mise en images d’une API par un développeur front avec React. Outre l’API, son travail repose aussi sur des maquettes et des userstories

↑ — Revenir au sommaire

3.5.3- Exemples

Exemples de mise en place d’un back et d’une API REST avec Express, et mise en images de cette API avec React :

✨ Divin :

✨ Origines du cinéma :

↑ — Revenir au sommaire

Depuis que JavaScript a fait sa révolution, le web n’est plus le même !

Lisez aussi :

1 commentaire pour “La révolution du JavaScript”

  1. Retour de ping : NVM, pour bien commencer la journée - Architecte de l'information

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partagez
Tweetez
Partagez