15 alternatives à React, Angular ou Vue (2e partie)

En matière de développement, il ne sert à rien de recommencer ce qui a déjà été très bien fait par d’autres. Il n'en va pas différemment en matière de frameworks JavaScript. Il est préférable de partir d’une base construite par une très bonne équipe de développeurs open source plutôt que de tout refaire depuis le début. Encore faut-il choisir la bonne base. En dehors des très populaires React, Angular ou Vue, il existe ainsi une variété d'autres frameworks. La sélection que nous vous proposons en passe une quinzaine en revue. Sept d'entre eux ont déjà été abordés dans une 1ère partie : Petit DOM, Surplus, RE:DOM, Mithril, Bobril, Marko et Svelte. Voici les suivants.

8 - Inferno

Parmi les autres frameworks créés pour faire principalement ce que fait déjà React, on trouve Inferno, mais avec un téléchargement réduit et un runtime plus rapide. Il parvient à ce résultat principalement en se débarrassant du mécanisme élaboré de « synthetic event » (événements créés par le programmeur par opposition aux événements résultant d’une action) et en se concentrant uniquement sur les plus essentiels comme onClick. Pour le reste, de nombreuses parties de l’API sont similaires, voire identiques à React, ce qui simplifie la migration du code si l’on n’a pas besoin de la couche d’optimisation sur les événements.

9 - Preact

L’un des plus petits descendants de React est Preact, un hommage qui offre la plupart des fonctionnalités les plus intéressantes du framework phare, comme un DOM virtuel et des composants sophistiqués, mais qui, lui aussi, s’est débarrassé des gestionnaires d’événements synthétiques et d’une partie de l’héritage autour des props (données immuables). Alors qu’Inferno se concentre uniquement sur la mise en œuvre des événements les plus importants comme OnClick, Preact ne se préoccupe pas du tout des événements, laissant le développeur s’appuyer sur la fonction native addEventListener du navigateur. C’est en laissant de côté les fonctionnalités qui n’apportent pas grand-chose (selon eux), que les promoteurs du projet ont réussi à réduire autant leur téléchargement. Il s’agit tout de même d’un compromis parce que Preact est un peu plus lent qu’Inferno. Bien sûr, l’application que l’on développe peut être différente et l’usage peut varier. Et si l’on a vraiment besoin d’une stricte compatibilité avec React, il existe même une librairie (preact-compat) qui apporte une réponse à la plupart des problèmes pendant la phase de build.

10 - Hapi

De nombreux frameworks arrivent en un seul morceau. Hapi ressemble davantage à un ensemble de plug-ins, une constellation de portions de code que l’on peut assembler dans sa pile au fur et à mesure que l’on en a besoin. Authentification, autorisation et connexion sont des tâches qui peuvent être résolues avec différentes options. Si l’on bâtit une architecture de microservices remplies d’API, le plug-in standardisé Swagger va automatiquement générer la documentation Swagger à partir du code de base.

11 - Koa

Il arrive parfois que l’on ait besoin d’un grand nombre de routines assez complexes pour jongler avec les requêtes entrantes et les traduire de multiples façons, quelquefois sous des formes assez élaborées. Koa est conçu pour simplifier un peu l’organisation de tout cela. Son secret, c’est de transformer les fonctions callback qui dominent normalement JavaScript en un ensemble de fonctions asynchrones qui se déclenchent au moment où il faut. Les empilements de callbacks qui s’enchevêtrent prennent alors un aspect un peu plus net.

12 - Nest

Une autre option pour apprivoiser la complexité du serveur est proposée par l’équipe de Nest qui offre une architecture peuplée de contrôleurs, de canaux et de fournisseurs, auxquels s’ajoutent des gardes, des intercepteurs et des filtres d’exception qui interviennent pour maintenir l’ordre. Le framework est moderne et il est d’emblée prêt à fonctionner avec GraphQL et avec des requêtes de microservices.

13 à 15 - Drupal, WordPress et Rails

En ce moment, les frameworks bâtis en JavaScript et fonctionnant au-dessus de Node.js constituent un peu le centre psychologique du monde du développement web. Mais cela peut être une erreur d’ignorer la précédente génération reposant sur PHP, une fondation devenue plus rapide que jamais maintenant qu’elle possède aussi un compilateur just-in-time à l’instar de JavaScript. On peut donc aussi chercher du côté de Drupal ou WordPress. De même, Ruby et son framework Rails constituent la pierre angulaire de bien des sites web solides comme un roc.

La dernière génération de ces outils est éprouvée et elle a été bien testée au cours de plus de dix ans de développement continu et de travail. On trouve des designers très avancés pour concevoir des thèmes et des apparences pour les applications. Et il y a de grandes chances pour que quelqu’un ait déjà réalisé les modules apportant les fonctionnalités dont on a besoin. Donc, avant de partir à la découverte d’un framework Node.js de pointe, il convient de vérifier si l’une des bonnes vieilles solutions que l’on connaît depuis longtemps ne peut pas faire l’essentiel, voire la totalité, de ce qu’il nous faut.

Et sinon, du JavaScript pur jus avec Vanilla JS

On pourrait le voir comme une parodie du conte d’Andersen « Les habits neufs de l’empereur », mais il est difficile de nier son succès. Vanilla JS est un site web qui se vante que son framework est déjà utilisé sur plus de sites que jQuery, Prototype JS, MooTools, YUI et Google Web Toolkit réunis. C’est peut-être vrai, sans doute non compte-tenu de la prolifération de jQuery, mais il vaut mieux en rire. Le site propose un petit sélecteur qui permet de réunir dans une archive personnalisée différents composants JavaScript comme Math, DOM, Closures et des expressions rationnelles. Peu importe ce que vous choisissez, le résultat pèsera toujours trois fois rien. Le plus drôle, c’est que cela peut quelquefois avoir du sens d’utiliser seulement certains éléments standards de JavaScript et d’en écarter d’autres.

Les bibliothèques et frameworks comme jQuery ou React ont démarré en partie à cause des incroyables différences qui existaient entre les navigateurs web. Grâce à la standardisation, une grande partie de ces différences a disparu. Bien sûr, les partisans de Vanilla JS ne dénient pas que des fonctions abrégées comme $( ) ne sont pas simplement pratiques, elles permettent aussi de gagner de la place dans son propre code. Mais si l'on prévoit seulement d’utiliser document.getElementById de façon occasionnelle, il est possible que cela n’ait pas d’importance. Pour ceux qui veulent juste ajouter quelques fonctions à leur page web pour faire des choses basiques, utiliser tout simplement JavaScript peut alors constituer la solution la plus rapide.