L’avenir des outils de construction frontaux

Les outils de construction frontend sont cruciaux pour le flux de travail du développeur frontend moderne pour une multitude de raisons classées dans l’amélioration des expériences des développeurs et des utilisateurs. Du point de vue du développeur, l’outillage frontal nous donne : la possibilité de créer des modules, un serveur de développement pour le développement local, le remplacement de module à chaud (HMR) pour une boucle de rétroaction plus courte en mode développement, la possibilité de cibler les navigateurs hérités avec des polyfills, le traitement d’un hôte de types de fichiers en dehors de JavaScript, la liste est longue.

En conséquence, les utilisateurs peuvent profiter d’applications plus performantes et riches en fonctionnalités qui restent performantes grâce à des techniques telles que le fractionnement de code, la mise en cache, la prélecture et d’autres techniques d’optimisation des ressources, certaines applications pouvant même fonctionner hors ligne.

L’outillage frontal nous donne tellement aujourd’hui qu’il est difficile d’imaginer qu’il fut un temps où il n’était même pas nécessaire du tout. Un voyage dans le passé pourrait nous aider à comprendre comment nous en sommes arrivés là.

Le passé

Avant que les applications frontales ne deviennent aussi complexes qu’elles le sont aujourd’hui, tout ce que JavaScript était utilisé était d’ajouter une interactivité de base à des documents HTML par ailleurs simples – de la même manière que Flash d’Adobe était utilisé.

Il n’y avait pas d’applications complexes « lourdes en JavaScript », donc aucun outil n’était nécessaire pour améliorer la création et la livraison de JavaScript, mais cela ne resterait pas le cas.

Au fur et à mesure que le temps passait et que nous commencions à créer des expériences utilisateur plus impliquées sur le Web, nous sommes passés de pages Web plus statiques à des applications Web hautement dynamiques servant des données spécifiques à l’utilisateur. Ces applications nécessitaient plus de JavaScript que leurs homologues traditionnels, et les limites de l’utilisation de JavaScript sont devenues beaucoup plus apparentes.

Il existe deux manières principales de charger JavaScript dans le navigateur. L’un est avec une balise de script référençant un fichier JavaScript, et l’autre consiste à écrire votre JavaScript directement dans les balises de script HTML à l’intérieur.

<script src="https://smashingmagazine.com/2022/06/future-frontend-build-tools/my-javascript-file.js"></script>

<script>
    var a = 1;
    var b = 2;

    var result = a + b;
</script>

Cette limitation du chargement de JavaScript devient un goulot d’étranglement lorsque vous avez beaucoup de JavaScript à charger. Il existe des limitations de navigateur pour charger de nombreux fichiers JavaScript simultanément et des problèmes de maintenabilité avec un seul fichier JavaScript volumineux (comme la taille du fichier, les problèmes de portée, la collision d’espaces de noms, etc.).

Nous avons proposé des solutions telles que les expressions de fonction immédiatement invoquées (IIFE) pour faciliter l’encapsulation et certains des problèmes de portée, après quoi nous avons acquis la possibilité d’écrire notre JavaScript dans de nombreux fichiers différents. Ensuite, nous avions besoin d’un moyen pour que ces nombreux fichiers soient combinés en un seul fichier à servir dans le navigateur

Le présent

Pouvoir diviser notre JavaScript en différents fichiers avec les IIFE, il semblait que tout ce dont nous avions besoin était un moyen de concaténer ces fichiers et d’envoyer un seul fichier au navigateur. Ce besoin a vu l’essor d’outils comme Gulp, Grunt, Brocolli, etc. Cependant, nous nous sommes vite rendu compte que notre pensée était peut-être un peu trop simpliste.

Au fur et à mesure que nos applications devenaient de plus en plus complexes, des problèmes tels que l’absence d’élimination du code mort, les reconstructions complètes pour de petites modifications et d’autres problèmes de performances nous ont fait réaliser que nous avions besoin de quelque chose de plus qu’une simple concaténation. Cela a donné naissance aux bundlers plus modernes comme Webpack, Parcel et autres.

Le rythme d’avancement dans l’espace frontal ne ralentissant pas, nous avons commencé à observer des lacunes et des problèmes avec les outils de construction modernes.

Certaines des principales limitations incluent :

• Installation et configuration complexes de certains de ces bundles existants ;
• Augmentation des temps de construction à mesure que les applications deviennent plus grandes ;
• Performances sous-optimales en mode développement.

La vitesse à laquelle les choses changent dans l’écosystème JavaScript est souvent fatigante, mais l’avantage est que la communauté identifie rapidement les problèmes et se met au travail sur des solutions potentielles. Avec notre objectif d’améliorer les performances de l’outillage frontal, une nouvelle génération d’outils de construction est en cours de développement.

L’avenir

Les limites des outils de construction traditionnels de l’époque ont conduit à plusieurs tentatives pour réinventer ce qu’un outil de construction frontal devrait être et faire, et il existe aujourd’hui un certain nombre de nouveaux outils de construction dans la nature.

Une inspection plus approfondie révélera que ces nouveaux outils semblent adopter deux approches majeures pour résoudre le problème (pas nécessairement mutuellement exclusives) : un changement de paradigme et un changement de plate-forme, tous deux alimentés par les nouvelles avancées de l’écosystème de développement Web.

A Replatform

Les outils de construction frontend ont traditionnellement été construits avec JavaScript et, plus récemment, Typescript. Cela avait du sens, car JavaScript est le langage du Web, et la création d’outils de création pour le Web dans le même langage permet à plus de personnes de contribuer plus facilement à l’effort et de créer une communauté autour de ces outils. Pourtant, il y a des problèmes inhérents à cette approche.

En tant que langage de haut niveau, JavaScript ne peut pas atteindre les niveaux de performances natifs. Cela signifie que les outils construits au-dessus de cette plate-forme ont un plafond sur leur performance. Ainsi, pour sortir de cette limitation, de nouveaux outils de construction sont construits sur des langages de niveau inférieur, intrinsèquement plus performants, comme Rust.

Des langages comme Rust et Go sont devenus des options populaires pour créer la prochaine génération d’outils de construction avec un fort accent sur les performances. Rust, en particulier, est populaire non seulement pour ses performances, mais aussi pour son expérience de développement impressionnante – élu le langage de programmation « le plus aimé » six années de suite dans le Enquête auprès des développeurs Stack Overflow.

En parlant de la décision de construire Rome (l’outil de construction et non la ville) avec Rust, Jamie Kyle dit :

«Beaucoup d’autres ont communiqué les performances, la mémoire et les avantages de sécurité de Rust avant nous – disons simplement que tous ceux qui ont déjà dit que Rust est bon ont raison. Cependant, notre plus grande préoccupation était notre propre productivité.
[…]
Après quelques prototypes, cependant, nous avons rapidement réalisé que nous pourrions en fait être plus productifs dans Rust »

— Jamie Kyle dans Rome sera écrite en rouille

Le projet CFC est à la pointe de cette idée d’utiliser Rust pour les outils de construction frontaux. Il alimente désormais des projets tels que le nouveau compilateur de Next.js, Deno, Parcel et d’autres, avec des performances qui dépassent de plusieurs ordres de grandeur les autres outils de construction existants.

Des projets comme SWC prouvent qu’avec un changement de plate-forme sous-jacente, les performances des outils de construction peuvent être considérablement améliorées.

Un changement de paradigme

La façon dont un pipeline de construction frontal typique fonctionne aujourd’hui est que vous créez des modules JavaScript dans de nombreux fichiers différents, exécutez une commande, l’outil de construction récupère ces modules, les regroupe en un seul module, les convertit dans un format compris par les navigateurs et sert cela fichier dans le navigateur.

Pour améliorer les performances en mode de développement, de nombreuses optimisations qui prendraient plus de temps sont laissées de côté et sont plutôt exécutées lorsque nous regroupons notre application de production. Cela garantit qu’il faut le moins de temps possible pour lancer un serveur de développement, exécuter notre application en mode développement et devenir productif.

Le processus de regroupement prend encore un certain temps, cependant et à mesure qu’un projet grandit, les temps de construction (même en développement) ne font que s’allonger. Ne serait-il pas formidable si nous pouvions d’une manière ou d’une autre ignorer complètement le regroupement tout en étant capable d’écrire des modules comme d’habitude et que le navigateur comprenne comment travailler avec eux ? Un nouvel ensemble d’outils de construction adopte cette approche, connue sous le nom de développement dégroupé.

Le développement dégroupé est formidable. Il résout un problème majeur avec les outils de construction existants : ils doivent souvent reconstruire des sections entières de votre application pour des modifications de code même insignifiantes, et les temps de construction s’allongent à mesure que l’application se développe. Nous perdons le retour rapide, essentiel pour une expérience de développement agréable.

On pourrait se demander, si le développement dégroupé est si important, pourquoi n’est-il pas la norme aujourd’hui ? Il y a deux raisons principales pour lesquelles le développement dégroupé commence seulement à gagner du terrain : la compatibilité des navigateurs pour les fonctionnalités de pointe et le traitement des importations de modules de nœuds.

1. Compatibilité du navigateur pour les fonctionnalités de pointe

Unbundled Development est optimisé par ES Modules (ESM), qui apporte un système de modules standardisé à JavaScript, pris en charge de manière native sur plusieurs environnements d’exécution, y compris le navigateur. Avec cette nouvelle capacité, nous pouvons marquer nos balises de script comme des modules et pouvons par conséquent utiliser le import et export des mots-clés que nous connaissons tous ;

<script type="module" src="https://smashingmagazine.com/2022/06/future-frontend-build-tools/main.js"></script>

<script type="module">
  /** JavaScript module code goes here */
</script>

Les modules ES existent depuis un certain temps. Pourtant, nous ne pouvons commencer à en profiter que pour des choses comme le développement dégroupé, principalement en raison du temps que sa normalisation a pris pour tous les acteurs de l’écosystème Web.

Dans son article sur les modules ES, sur Mozilla Hacks, Lin Clark déclare :

« Les modules ES apportent un système de modules officiel et standardisé à JavaScript. Cependant, il a fallu du temps pour en arriver là – près de 10 ans de travail de normalisation.

— Lin Clark dans Modules ES : une analyse approfondie des dessins animés

Le problème de la prise en charge du navigateur ou de son absence a longtemps entravé le développement frontal. C’est pourquoi nous avons un fournisseur préfixant notre CSS, parfois la raison des polyfills, pourquoi nous passons du temps à assurer la prise en charge multiplateforme de nos applications Web et pourquoi cela prend parfois un certain temps avant de pouvoir profiter des dernières et meilleures fonctionnalités Web. dans notre travail quotidien.

Essayez de visiter un StackBlitz projet utilisant Safari, et vous serez accueilli avec l’écran suivant communiquant le manque de prise en charge des WebContainers dans les navigateurs non basés sur Chromium.

Le rythme d’adoption des fonctionnalités n’est pas le même d’un fournisseur de navigateur à l’autre, et il existe souvent des variations dans la façon dont les différents fournisseurs implémentent certaines fonctionnalités. Cependant, l’avenir s’annonce prometteur avec des initiatives comme Interop 2022.

2. Traitement des importations de modules de nœud

La plupart, sinon la totalité, des applications frontales que nous écrivons aujourd’hui dépendent de bibliothèques externes de NPM. Pour une application React typique, nous importerions React en haut de nos fichiers de composants comme suit :

import React from 'react'

/** The rest of your component code */

Essayer de charger cela directement dans le navigateur, comme nous aurions besoin de le faire pour un développement dégroupé, entraînerait deux problèmes. Tout d’abord, le navigateur ne sait pas comment résoudre le chemin pour trouver react et deuxièmement, la bibliothèque de réaction est publiée en tant que module Common JS (CJS) – qui ne peut pas s’exécuter nativement dans le navigateur sans un prétraitement.

Ce dernier est le plus gros problème ici, car il est possible, et même trivial, de simplement remplacer nos importations de module de nœud par des chemins relatifs vers des fichiers spécifiques. Néanmoins, le fait que la plupart des packages NPM soient écrits dans un format de module plus adapté à Node JS que le navigateur nécessite que nos dépendances NPM soient traitées spécialement pour faciliter le développement dégroupé.

Manteau neigeux, en particulier, gère cela en traitant les dépendances de l’application dans des fichiers Javascript distincts qui peuvent ensuite être utilisés directement dans le navigateur. Plus d’informations sur la façon dont Snowpack fait cela peuvent être trouvées ici.

Les modules ES étant désormais courants dans la plupart des navigateurs modernes et des solutions de contournement intelligentes pour les dépendances NPM, créez des outils tels que Vite et Manteau neigeux peut offrir la possibilité d’un développement dégroupé avec des performances considérablement améliorées, des versions rapides, en plus d’un HMR ultra rapide.

Dernières pensées

Le développement frontend a parcouru un long chemin, et nos besoins évoluent constamment et deviennent de plus en plus complexes. Les outils de construction sont une partie essentielle de la façon dont nous créons des applications frontales, et les outils existants ne sont pas à la hauteur, ce qui déclenche le développement de nouveaux outils qui réinventent la façon dont les outils de construction doivent être conçus.

En mettant l’accent sur les performances, la facilité d’utilisation et une configuration moins complexe, la prochaine génération d’outils de construction est prête à alimenter des applications frontales ambitieuses pendant un certain temps encore.

Êtes-vous enthousiasmé par les développements récents dans cet espace? Faites-moi savoir dans les commentaires ce que vous pensez des innovations à venir et du paysage actuel.

Lectures complémentaires sur Smashing Magazine

(nl)