Comment le frontend se réinvente tous les jours ?

Meet-up IT Peaks sur le frontend : Comment le frontend se réinvente tous les jours ? Crazy frontend Peaks Méditerranée

Peaks Méditerranée a accueilli la communauté AixJS pour un meet-up avec deux talks pour approfondir les joies et les mystères du frontend.

Cyclic web evolutions:
De PHP à NextJS et au delà

Talk 1 by Timur Rustamov – Gojob

Le web a drastiquement changé depuis son invention par Tim Berners-Lee en 1989 – nous avons réussi à y incorporer une richesse incroyable, une complexité folle et notre communauté de développeurs a grandi de manière exponentielle. Les abstractions, les syntaxes et les modèles mentaux sont les principaux drivers de cette évolution et forment un cercle vertueux – se réincarnant à travers le temps et les technologies qui les utilisent. Dans cette présentation, nous allons voyager dans le temps et essayer de faire une rétrospective. Pourquoi NextJS est le nouveau PHP, d’où vient la syntaxe JSX, et comment le framework frontend AngularJS a conquis le monde.

Rétrospective de 30 ans sur ce qui s’est passé dans le monde du web

Le 12 mars 1989, Tim Berners-Lee travaillant au CERN, en Suisse, a écrit le papier « Information Management : A Proposal » où il décrit les bases de ce qui est désormais le web.

Il écrit que le rêve derrière le web est de créer un espace commun de partage où celui-ci se fait par l’information. Cette universalité est pour lui essentielle : le fait qu’un hyperlien puisse emmener sur n’importe qu’elle page, qu’elle soit privée ou public. L’idée est d’avoir un espace de partage commun à tous.

Le 6 aout 1989, Tim Berners-Lee et son équipe ont mis en ligne le premier site web, partagé dans les internets mondiaux. Le web est né ce jour-là.

Qu’est ce que le web finalement ?

Le web est un fichier écrit en langage du web, le HTML. La particularité de ce document est qu’il contient des hyperliens qui peuvent nous emmener sur d’autres pages ou sur d’autres ressources qui se trouvent également sur le web, les interconnectant les uns aux autres.

Ces hyperliens contiennent des URL qui, dans leurs compositions, identifient le site web et le chemin vers la page qui contient le document. Le site web est un ordinateur connecté à internet et la page web est le fichier qui se trouve dans un document de l’ordinateur. On communique avec les autres ordinateurs grâce à un protocole HTTP, dédié pour le web.

En 1993, Mosaic, le premier navigateur internet débarque. Il permet alors d’utiliser le World Wide Web.

Dans les premières années du web, il s’est passé une tonne de choses :

  • Des nouveaux sites
  • De nouvelles expériences créées
  • De nouvelles entreprises concentrées sur le web

Dans ces années, la guerre des navigateurs internet a commencé : Netscape, Internet Explorer, Firefox et Opera.

Le web a également évolué au cours des années en terme de technologies :

  • JavaScript / JScript en 1995
  • CSS en 1996
  • Macromedia Flash en 1996
  • WAP en 1998

En 1998, le web était plus ou moins statique.

PHP, le premier langage créé et pensé pour le web

éléphant logo PHP

Ce langage a permis de simplifier :

  • Les formulaires HTML
  • La génération de pages web
  • L’accès aux cookies et aux variables d’environnements

On s’est alors posé la question suivante : les pages web peuvent-elles devenir des applications web à proprement parler ? Ce langage, introduisant des nouveaux URL grâce à l’extension .php, signifiait qu’il y avait un programme PHP derrière ça.

N’importe quel fichier HTML peut être processé par le PHP. On peut y introduire le comportement d’une application web.

Cela a donné naissance à la première stack du monde web, la LAMP stack :

  • Linux
  • Apache
  • MySQL
  • PHP

A l’époque, JavaScript est considéré comme compliqué. jQuery a été une libération de part sa simplicité.

jQuery, l’outil essentiel de JavaScript

jQuery a simplifié beaucoup de choses, il nous a aidé à traverser le DOM et manipuler les identités dans le DOM, à rattacher des events handler, gérer les animations. L’une des principales évolutions de jQuery était l’introduction de AJAX (Asynchronous JavaScript).

On pouvait, depuis la page web qui était déjà chargée, faire des requêtes au serveur et obtenir de l’information et la traiter. Avant, toute la page était chargée. Grâce à AJAX, on va chercher de l’information appropriée pour faire le changement d’étape sur l’application web.

Cependant, jQuery n’est pas du tout scalable :

  • La complexité devient petit à petit extra folle
  • La source de vérité était perdue dans le DOM
  • Tout est global

L’arrivée d’Angular JS, le framework frontend

Crée par google en 2010, c’est la création de cet esprit SPA (Single Page Application).

A l’époque, les features exceptionnelles d’AngluarJS :

  • Le routage : créer ses vues et naviguer dans le browser sans faire de requête backend
  • Le couplage faible : entre le MVC et le contrôleur
  • Le bidirectional models : le data binding.
  • L’injection de dépendance, une première à l’époque dans le monde du frontend.

Grâce à toutes ces innovations, le framework frontend est devenu extrêmement populaire jusqu’en 2016 environ.

React JS

En 2013, React JS est arrivé, créé par Jordan Walke de Facebook, qui a proposé un changement de paradigme complet par rapport à ce qui existait avant.

En quoi ce paradigme a changé ?

  • Désormais, les user interfaces sont composées de composants. Chaque component peut être indépendant, avec son cycle de vie.
  • One way data flow : un état peut être recetté par une fonction
  • Une vue est une fonction d’un état interne de notre composant et de ses propriétés
  • JSX, apparu vers 2014
  • L’activation du Server-Side Rendering (SSR), un mix parfait entre les Multi Page Application (MPA) et les Simple Page Application (SPA)

Next.JS

En 2016, Next.JS a été lancé. Ce framework autour de React permet alors de gérer tout ce qui est SSR et plus encore, avec une facilité incroyable.

Qu’est-ce que propose Next.JS ?

  • Créer une application frontend fullstack avec un serveur et un client side intégré.
  • Lorsqu’elle a déjà été chargée une fois et qu’on navigue, il n’est pas nécessaire de charger à nouveau la page entière.
  • Sont proposés : Server-Side Rendering (SSR), Static Site Generation (SSG) et Incremental Static Regeneration (ISR)
  • File-based routine

Nous pouvons constater une certaine tendance du développement web frontend, d’effacer les barrières entre le serveur et les clients pour amener une meilleure DX et de la performance dans le frontend et proposer de meilleures expériences aux utilisateurs.

Le web a beaucoup changé en 30 ans mais son but est le même. L’idée de Tim Burners-Lee est la suivante : « Il y avait une seconde partie du rêve, dépendant du fait que le web soit si largement utilisé qu’il devienne un miroir réaliste des façons dont nous travaillons, jouons et socialisons. »

Standalone components / Signals :
Comment Angular évolue pour améliorer l’expérience développeur

Talk 2 by Grégory Servera – Peaks

Depuis sa création, Angular est en perpétuelle évolution afin d’apporter aux développeurs une meilleure expérience. Aujourd’hui, les Standalone Components permettent de s’affranchir de la lourdeur des modules. Demain, les Signals simplifieront la réactivité de l’UI en évitant la verbosité de RxJS tout en favorisant la détection de changement « OnPush ». Lors de ce talk, nous allons vous présenter ces nouvelles features, ce qui sera aussi l’occasion de discuter des grandes étapes qui ont amenés à ces évolutions du framework.

Le long voyage des modules

Les deux principales phrases que l’on peut retrouver sur la première documentation d’Angular 2 au sujet des modules :

  • « Les modules servent à organiser une application dans des blocs cohérents de fonctionnalités »
  • « Les modules consolident les composants, les directives et les pipes dans des blocs cohérents de fonctionnalités »

En résumé, les modules devraient servir à :

  • organiser une application en blocs cohérents
  • consolider les composants, pipes, services etc. qui vont ensemble

Mais Angular en avait besoin pour :

  • savoir quels sont les composants, pipes, services, etc.
  • importer des composants, pipes, services, etc. externes
  • avoir un graph pour son injection de dépendances

Lorsque l’on a un composant qui a besoin d’un service, Angular, grâce à cette méthode là, sait où trouver le service, comment l’instancier et quelle dépendance lui fournir. Les modules consolident tous ces mécanismes, en réalité plus que consolider le code.

Un mouvement progressif est ensuite apparu pour diminuer l’importance des modules. En 2016, Angular 2 sort. 2 ans plus tard, il diminue l’importance des modules sur les services. En 2020, la propriété « entryComponents » a été dépréciée. Ces composants étaient injectés par du TypeScript. L’année dernière (2022) marque l’arrivée des standalone components (pipes, directives).

Les standalone components

Les standalone components servent à déclarer des composants qui se suffisent à eux-mêmes. Chaque composant déclare uniquement les dépendances dont il a besoin. C’est la fin des modules pour déclarer les composants, les dépendances. Cela facilite également l’identification d’une dépendance devenue inutile.

Grâce aux standalone components, l’application finale est simplifiée. Les composants qui sont déclarés dans des modules sont compatibles avec les Standalone Components et inversement. Ils peuvent cohabiter dans une même application. Pour faciliter la migration, il existe dans @angular/core un schematic, mais il a ses limites : un développeur doit finir le travail.

Les Signaux du framework frontend Angular

Angular 16 intègre le concept de Signal, une autre façon de faire une application réactive.

Les signaux sont : une implémentation simple du pattern Observer. Contrairement à RxJS, c’est Angular qui observe le signals. De notre côté, on se soucie uniquement de la valeur, de sa mise à jour et de son éventuelle transformation (computation)

Signal supplante t-il RxJS ?

Les signaux sont synchrones, on démarre toujours avec une valeur. Les observables sont faits pour être asynchrones, ce sont leur logique.

RxJS permet :

  • d’exploiter des opérateurs variés et puissants
  • de combiner des observables de différentes façons (mergeMap, switchMap, etc.)

Signaux et observables sont donc complémentaires, mais pas aux mêmes endroits. L’équipe d’Angular l’a bien compris. Actuellement, en PR, un travail est fait pour donner deux fonctions et facilement passer de l’une à l’autre.

Standalone components / Signals

Deux mouvements progressifs :

  • retirer la lourdeur des modules pour simplifier et faciliter la gestion des dépendances
  • la réactivité et la détection du changement. Par défaut, Angular, dès qu’un clic ou qu’un mouvement de souris est fait, redéclenche une série de détection de changement sur l’entièreté du DOM et des composants.

Comment Angular détecte ce changement ? Il utilise une librairie : Zone.JS, qui déclenche Angular à chaque action (exemple : clic) et le surchage. Au chargement de l’application puis à chaque clic, nous avons un temps mort sur Zone.JS. La détection de changement OnPush ainsi que les signaux vont aider à corriger ce problème là. Parce qu’à partir du moment où l’on ne s’appuie plus sur une détection de changement systématique mais où l’on signale par choix le changement, Zone.JS ne sert plus à rien. Des réflexions sont alors actuellement en cours au sein de l’équipe d’Angular pour se défaire de Zone.JS.

Charlene

Voir nos offres
Espace Carrière
Inscrivez-vous à la newsletter :
Ces articles peuvent vous intéresser