Choisissez votre propre aventure JavaScript

Le fait que JavaScript (JS) soit devenu de facto le deuxième langage de programmation pour tous les développeurs d'applications web a quelque chose d'assez remarquable. C'est assez impressionnant, si l'on considère que le nom lui-même a été choisi pour s'aligner sur le langage de programmation Java, bien qu'il soit fondamentalement complètement différent. L'année dernière, j'ai écrit que le succès de PHP était dû à son évolutionet on peut certainement affirmer que le seul autre langage qui a connu le même niveau d'évolution, si ce n'est plus, est le JS. Mais comment aborder cette vaste pile d'options ? Je me suis inspiré de cet article désormais légendaireque je me souviens avoir lu à l'époque et m'être délecté de la complexité des choses. Dans cet article, nous allons passer en revue les origines, les avantages et les inconvénients de ce qui a fait cet écosystème complexe.

Origines

Back To The BeginningLes limites de Vanilla JS ont été couvertes par la première version de la grande bibliothèque : jQuery. De nos jours, jQuery tend à être la cible de plaisanteries en raison des problèmes qu'il a résolus en étant intégré nativement dans le langage, mais il est probablement utile de noter que jQuery détient toujours une part de marché de 90 % sur les sites web en 2025. La complexité des frameworks frontaux modernes tels que Vue et React est totalement compensée par la simplicité de jQuery pour les applications plus simples.

Node renverse le scénario

Ryan Dahl a vraiment tout changé en 2009. À cette époque, le moteur V8 de Google dans le navigateur Chrome, JScript dans Internet Explorer et SpiderMonkey dans Firefox étaient les principaux moteurs d'exécution utilisés pour leurs navigateurs respectifs. Dans un véritable moment d'innovation, Ryan a posé la question suivante : "Et si vous retiriez le moteur V8 et l'exécutiez plutôt sur un serveur ?". Et c'est ce qui s'est passé, Node est né, sans se douter que tous les futurs développeurs ne sauraient plus exactement comment décrire ce que c'est réellement aux gens. S'agit-il d'un cadre de travail ? Non. S'agit-il de JavaScript ? Non. "Un moteur d'exécution et des chaînes d'outils périphériques" est une réponse correcte.

Gestion des paquets

Watch that node_modules directory grow!Une fois que vous avez un langage côté serveur, la prochaine étape logique est d'avoir un système de gestion de paquets. Le gestionnaire de paquets Node (npm) a été l'outil par défaut pendant des années, mais comme nous l'avons déjà vu, l'écosystème JavaScript reste rarement immobile pendant longtemps. Non content des performances offertes par la résolution des dépendances, Facebook a créé Yarn en 2016. Yarn a vu l'introduction d'un nouveau fichier de verrouillage et, surtout, d'une mise en cache hors ligne. L'amélioration des performances peut être assimilée à l'évolution de développement de PHP7 en réponse à HHVMnpm a donc considérablement amélioré ses performances et s'est attaqué aux problèmes qui ont conduit au développement de Yarn en premier lieu. Par conséquent, le sempiternel "cela dépend de vos préférences" est la réponse réaliste à la question "Que dois-je utiliser ?".

J'ai ES6é tous vos modules communs

À l'origine, JavaScript ne disposait pas d'un système modulaire permettant d'exporter des fichiers et des propriétés/fonctions. L'essor de Node et la mise à l'échelle considérable des applications web, qui rivalisent avec les applications natives des systèmes d'exploitation, tant au niveau de la partie frontale que de la partie dorsale, nécessitaient de remédier à cette situation. Cela s'est fait sous la forme de CommonJSune norme qui permettait d'importer des éléments à l'aide de la méthode require() pour permettre les importations.

Comme nous l'avons vu ailleurs, JavaScript est plein de développeurs qui essaient de résoudre des problèmes existants, et l'un d'entre eux était l'activation des exportations par Node avec CommonJS. Par conséquent, la solution permanente serait : comment obtenir l'importation/exportation native en JavaScript ? En 2015, ECMAScript l'a fait avec l'ajout de la fonction ESM (ECMAScript Modules).

Selon un schéma que vous commencez probablement à remarquer, vous disposez donc de deux méthodes différentes pour la mise à l'échelle des applications. "Vous vous demandez : "Que dois-je utiliser ? Encore une fois, la réponse technique est "celle qui vous convient", mais ce n'est pas tout à fait exact. Pour les nouveaux projets, il est recommandé d'utiliser ESM parce qu'il est natif et qu'il prend en charge le tree-shaking et l'analyse statique.

TypeScript à la rescousse

A Saviour Is BornLe problème de JavaScript dans le moteur du navigateur ou de Node est qu'il s'agit d'un langage faiblement typé qui tentera d'exécuter à peu près tout ce que vous essayez de faire. Les adeptes de Java, C# et autres langages compilés seraient probablement horrifiés par la capacité des développeurs JS à écrire des montagnes de code absurde (et c'est ce qu'ils ont fait) : Je me souviens très bien d'un outil frontal où tous les arguments de la fonction d'aide principale étaient simplement des variables sous forme de lettres simples épelant le nom du produit, qui restera anonyme). Il y a toujours quelqu'un pour remédier aux limites de JS, et dans ce cas particulier, c'était Microsoft.

Microsoft a développé un surensemble de JavaScript qui apporte un système de typage fort sous la forme à la fois d'un compilateur et d'un moteur d'exécution. d'un compilateur et d'un moteur d'exécution (qui peut être appelé avec npx). L'adoption de TypeScript a été assez phénoménale, en particulier lorsque les besoins des applications sont susceptibles d'évoluer rapidement. Chez Vonagenotre propre Node SDK a fait l'objet d'une réécriture totale par Chuck Reeves pour la version 3, qui l'a porté à TypeScript.

Compilation de la confusion

L'introduction de npm en tant que gestionnaire de paquets a créé un problème unique pour les développeurs frontaux : un nouveau dossier nommé node_modules existait dans les projets, mais comment transférer ces dépendances dans le code du frontend ? Avant npm, Bower s'occupait des dépendances frontales. Cependant, npm l'a pratiquement rendu superflu. Utilisé en conjonction avec npm, Grunt et Gulp sont utilisés comme des exécutants de tâches, le plus souvent avec des outils tels que Babel pour transpiler en JavaScript de niveau inférieur.

La solution de compilation unifiée est apparue sous la forme de Webpackqui compile tout un front-end en un fichier JS unifié basé sur un système d'actifs. Tous les fichiers CSS, les fichiers sources JS ou ceux issus de la gestion des paquets, les fichiers images, etc. Ajoutez-y le compilateur Typescript si vous en avez besoin et vous obtenez un constructeur puissant. Mais il y a toujours un "mais"...

J'ai beaucoup travaillé avec Webpack dans des agences et des entreprises commerciales, et je peux vous dire qu'une grande puissance s'accompagne d'une grande complexité. L'exécuter sur chaque build prend du temps, et le nombre de fois où il s'est effondré à cause de problèmes de configuration m'a donné envie d'éclater en sanglots. Alors, dans l'esprit de l'article : devinez ce qui s'est passé ensuite ? C'est vrai, quelqu'un est venu et a construit quelque chose d'autre. L'auteur de la bibliothèque VueJS (personnellement, Vue est le seul framework JS front-end avec lequel j'ai aimé travailler, mais c'est un sujet pour un autre jour) Evan You a créé Viteun compilateur et un serveur écrits à partir de zéro avec des benchmarks très élevés. Il a été adopté rapidement par Remix, Laravel, Nuxtet Astroce qui représente un portefeuille assez important.

Evolution du temps d'exécution : Deno et Bun.sh

The Journey Never EndsC'est ici que je vraiment l'évolution de JS. Là où Node a bouleversé la pile d'applications web, le temps avait prévu de créer de nouveaux problèmes. En 2009, les calculs Serverless et Cloud Native en étaient à leurs balbutiements. En 2016, les ingénieurs DevOps avaient des attentes élevées en matière de performances lorsqu'ils envoyaient des fermetures de fonctions entières dans Node à travers les runtimes de calcul des plateformes cloud. À ce stade, nous avions deux problèmes : les performances au niveau des des millions d'événements dans la boucle d'événements pour les applications à haute disponibilité et le système de paquets Node (qui était désormais également responsable de tout ce qui se passait dans le front-end) entrant dans un enfer de dépendances de proportions semblables à celles d'un mème.

Le premier problème a été résolu par le créateur initial de Node. En 2018, Ryan a annoncé Denoet deux ans plus tard, il a lancé la production de Deno. Deno ne pouvait évidemment pas "résoudre" l'enfer des dépendances qui avait émergé de npm du jour au lendemain, mais il a mis en place divers mécanismes qui normaliseraient tous les adoptants du runtime :

• Prise en charge de Typescript dès le départ, ce qui favorise l'émergence d'un code plus robuste.

• Utilisation des modules ESM par défaut, donc pas de mélange entre ESM et CommonJS.

• Suppression du gestionnaire de paquets par défaut. Avec la découverte de paquets par le biais d'URL uniquement, il a standardisé le temps d'exécution pour éviter qu'il soit étroitement lié à un outil de gestion (c.-à-d. npm).

• Une API plus rationalisée. L'un des principaux problèmes de Node était que de petits morceaux de code "devenaient effectivement essentiels". Absorber les bibliothèques les plus vitales dans une bibliothèque standard et couper le surplus était une décision intelligente, qui pourrait peut-être empêcher des choses telles que quelques lignes de code qui cassent l'internet.

La conclusion ne serait-elle pas que tout le monde déménage à Deno ? Eh bien, non. Parce qu'alors :

Bun.sh a été lancé en 2021. Je dois admettre que j'ai été surpris qu'un un autre runtime côté serveur soit publié. Que s'est-il passé ici ?

Deno était une réimagination de Node par son créateur, avec quelques décisions d'architecture pour arrêter directement les problèmes d'outillage et d'écosystème qui ont suivi Node. Bun, cependant, est vraiment allé en ville : il a lancé pour supprimer l'outillage optionnel de tierce partie essentiel à l'exécution de JS côté serveur. Cela signifie que :

• Prise en charge de TypeScript dès le départ, comme pour Deno

• Un programme de test intégré

• Un gestionnaire de paquets intégré

• Un transpondeur intégré

• Un bundler intégré (pensez à Vite ou au bundler de Ruby)

Tous ces produits ont été construits en Zigqui est comparable aux nouveaux langages de programmation de bas niveau qui ont remplacé les langages C ou C++, tels que Rust. "Mais lequel dois-je choisir ? vous demande-t-on une fois de plus. La vérité est qu'il n'y a pas de bonne réponse. Quiconque préconise l'un des deux se trompe sur un autre aspect de ce qu'il essaie de faire, et c'est tout simplement du JS complet pour vous.

Conclusion

J'espère que vous avez apprécié cette vaste aventure qu'est l'évolution de JS. Le fait est qu'il n'y a pas de bonne ou de mauvaise réponse lorsqu'il s'agit de choisir des piles et des outils. Je n'ai même pas abordé Astroou Svelteou Remixou Nuxtou suivant. Je ne suis qu'un humble développeur qui tente de livrer un logiciel. Avec la multitude de runtimes et d'outils disponibles, ce que je peux faire, c'est de l'argent. peux faire est de recevoir des suggestions sur les outils à utiliser pour les articles qui utilisent les API de Vonage ? Rejoignez notre communauté de développeurs sur Slackou suivez-nous sur X (anciennement Twitter), ou abonnez-vous à notre lettre d'information aux développeurs. Restez en contact, partagez vos progrès et tenez-vous au courant des dernières nouvelles, astuces et événements pour les développeurs !