« La Mélodie du bonheur » peut prêcher : « Commençons par le tout début, un très bon endroit pour commencer. » Mais presque tous les développeurs savent que c’est un plan insensé. Le bon endroit pour commencer est une fondation solide construite par une grande équipe de développeurs open source. Clonez leur travail acharné, puis ajoutez juste assez de code pour vous l’approprier. Il n’y a pas besoin de répéter ce que tout le monde a fait avant.
C’est un plan facile – une fois que vous choisissez. Malheureusement, choisir cette fondation peut être presque aussi difficile que de commencer au tout début. Le monde des frameworks web est un domaine de développement très actif et il peut y avoir des dizaines de bons projets open source qui seraient d’excellents débuts pour votre projet.
Pour aggraver les choses, les différentes équipes qui ont créé ces différents projets se sont engagées sur une voie différente parce qu’elles avaient de sérieuses différences philosophiques avec les autres options. Ils ont regardé les autres frameworks et ont décidé qu’ils pouvaient faire mieux. En d’autres termes, ils l’ont fait pour une raison et vous pouvez être d’accord ou non avec leur décision.
La liste des bons endroits où commencer ci-dessous laisse intentionnellement de côté les leaders du marché que sont React, Angular et Vue, juste pour simplifier un peu les choses. Cela ne signifie pas que les trois grands sont mauvais. Ils peuvent toujours être la bonne solution pour vous. C’est juste qu’on en parle constamment et que ces discussions laissent de côté d’autres options plutôt bonnes.
Il y a beaucoup de bonnes raisons de choisir le plus populaire. Beaucoup de personnes à votre place ont regardé autour d’elles et beaucoup d’entre elles ont choisi React, Angular ou Vue pour une bonne raison. Mais c’était à l’époque. Entre-temps, certaines personnes intelligentes ont créé de nouveaux frameworks plus rapides, plus simples, plus forts, ou tout autre ensemble de superlatifs.
Dans la plupart des cas ci-dessous, les équipes ont créé quelque chose d’intriguant et de puissant en réimaginant la nature du framework. C’est une façon fantaisiste de dire qu’ils ont fini par supprimer une fonctionnalité rendant ainsi le framework plus efficace et donc réduisant la quantité de mémoire dont il a besoin, accélérant le temps de démarrage, ou le rendant généralement plus agile. Ou dans quelques cas, ils ont ajouté de nouvelles idées qui pourraient devenir des standards à l’avenir.
Si vous avez le temps d’investir, voici une liste de certains des autres choix intéressants. Ils ne conviennent pas nécessairement à certaines personnes et ils ne sont certainement pas le meilleur choix pour tous, mais ils pourraient être un meilleur choix pour vous. Votre travail, si vous choisissez de l’accepter, est de créer une description solide de votre application web, d’écrire une description relativement ferme des différents cas d’utilisation, puis d’évaluer ces outils avec cela en tête.
Peut-être que vous aimez une approche particulière de la conception du code. Peut-être que votre application n’a pas besoin de certaines des fonctionnalités des frameworks les plus gros et les plus populaires. Il existe des dizaines de raisons d’investir dans l’une de ces autres voies. Vous pourriez juste trouver que l’un d’eux fait des merveilles pour votre application.
Petit DOM
Si vous aimez l’idée d’un DOM virtuel, mais que vous ne voulez pas toutes les contraintes qui viennent avec l’adoption de l’état d’esprit des gens de React, Vue, ou votre autre framework de grand nom, alors le Petit DOM est la voie à suivre. Vous obtenez une petite quantité de code qui vous permettra de manipuler une collection virtuelle de balises, puis de les migrer vers le vrai DOM. Tout le reste de la structure des composants et du rendu dépend de vous. Si vos composants sont simples, ou si vous avez l’intention de créer une hiérarchie de rendu super-complexe qui n’appartiendra qu’à vous, cela pourrait être votre base parce que tout ce qu’il fournit est un outil pour virtualiser le DOM.
Surplus
Le DOM virtuel peut ne pas être pour tout le monde. Il prend de la place, donc si vos manipulations ne sont pas trop complexes, vous pourriez aussi bien canaliser vos instructions directement vers le DOM officiel. C’est ce que fait la bibliothèque Surplus. Elle prend le JSX de balisage préféré de tout le monde et le compile en un code qui manipulera le vrai DOM. Comme on dit dans le monde de la publicité, elle supprime l’intermédiaire. Pas de différenciation. Pas de couche supplémentaire secrète. Juste une pure manipulation du vrai DOM. Si votre code est assez simple et direct pour faire juste quelques choses au DOM, pourquoi s’embêter avec la distraction virtuelle ?
RE:DOM
Une autre option pour ceux qui ne veulent pas investir de mémoire dans un Dom virtuel est une minuscule bibliothèque (2KB) appelée RE:DOM. RE:DOM contient quelques routines de base qui vous permettent de créer toutes vos balises et composants avec quelques appels JavaScript simples. La syntaxe est beaucoup plus proche de celle des CSS, de sorte que vous pouvez spécifier des balises assez élaborées avec des ID et des classes en quelques frappes. Vos touches « less than » (<) et « greater than » (>) vous remercieront.
Mithril
Les alternatives ne sont pas toutes minuscules et minimalistes. Mithril pourrait être appelé un framework « de taille moyenne » dans ce contexte, bien qu’il ne pèse qu’environ 8KB. Tout ce code construit un DOM virtuel avec un mécanisme de mise à jour efficace comme les autres, mais il est également livré avec un ensemble standardisé d’outils pour traiter de nombreux défis standard comme le routage et les appels XMLHttpRequest. Les concepteurs du projet veulent que les projets Mithril soient relativement standardisés, et ils pensent que l’ajout de ce code à la bibliothèque principale augmente la standardisation. Si cela ne suffit pas, ils poussent également un certain formatage standard et des structures idiomatiques.
Bobril
Si vous aimez le DOM virtuel et les composants avec état de React et que vous aimez programmer en TypeScript, alors Bobril ou son cousin Angular-friendly ngBobril peut être juste le ticket. Le framework est systématiquement beaucoup plus rapide que React ou Angular dans certains des benchmarks, peut-être en raison des algorithmes de comparaison plus rapides et de l’absence de prise en charge du JavaScript isomorphe. Il existe également des fonctions de raccourci pour la manipulation CSS et une couche de gestion d’état complète, BobX, si vous en avez besoin.
Marko
Si vous avez passé du temps à enchérir sur des distributeurs Pez ou d’autres objets de collection, vous avez fait l’expérience de la puissance de Marko, un framework mince et rapide qu’eBay partage via une licence open source. La partie la plus agréable est peut-être une syntaxe de modélisation très légère qui supprime intelligemment la plupart des excès de gras du HTML, de sorte que la structure est définie par l’indentation et pas grand-chose d’autre. Et le moteur de rendu est très rapide, capable de piloter des constellations élaborées de DIVs dansants qui se mettent à jour plus rapidement que 60fps.
Svelte
Votre framework web standard est livré avec un compilateur et une bibliothèque téléchargée qui gère à l’exécution ce que le compilateur produit. Ce processus en deux étapes permet un code très élaboré au prix de l’attente du téléchargement et de l’analyse de la bibliothèque d’exécution à chaque ouverture de la page. Le compilateur Svelte se débarrasse de cette complexité en produisant un JavaScript presque pur qui est presque prêt à s’exécuter tout seul, bien que seulement dans certains des navigateurs les plus récents (par exemple Chrome, Firefox, Opera et IE10). C’est un gambit architectural intelligent qui produit des sites Web très légers qui prennent peu de mémoire.
Inferno
Inferno est un autre framework créé pour faire beaucoup de ce que fait React, mais avec un téléchargement plus petit et un temps d’exécution plus rapide. Il réalise une grande partie de cela en jetant le mécanisme élaboré d’événements synthétiques et en se concentrant uniquement sur les plus essentiels comme onClick. De nombreuses autres parties de l’API sont similaires, voire identiques, ce qui rend relativement simple le transfert de votre code s’il n’a pas besoin de la couche d’optimisation des événements.
Preact
L’un des plus petits des descendants de React est Preact, un hommage qui offre la plupart des fonctionnalités les plus précieuses comme un DOM virtuel et des composants sophistiqués, mais dépouille les gestionnaires d’événements synthétiques et une partie de l’héritage des props. Alors qu’Inferno tente d’implémenter uniquement les événements les plus importants comme onClick, Preact ne prend pas la peine d’essayer de faire quoi que ce soit avec les événements, vous laissant compter sur le addEventListener natif du navigateur. En laissant de côté les fonctionnalités qui n’apportent pas grand-chose (selon eux), Preact réduit encore plus son téléchargement. C’est un peu un compromis car les benchmarks montrent que Preact est un peu plus lent qu’Inferno. Bien sûr, votre application peut être différente et votre kilométrage peut varier. Si vous avez vraiment besoin d’une compatibilité pure avec React, il y a même une bibliothèque (preact-compat) qui corrige la plupart des problèmes pendant la construction.
Hapi
De nombreux frameworks arrivent en un seul morceau. Hapi est plus une collection de plug-ins, une constellation de dizaines de bouts de code que vous pouvez mélanger dans votre pile comme bon vous semble. L’authentification, l’autorisation et la journalisation sont des tâches qui peuvent être résolues avec un grand nombre d’options. Si vous construisez une architecture de microservices pleine d’API, le plug-in Swagger normalisé générera automatiquement la documentation Swagger à partir de votre code de base.
Koa
Parfois, vous avez besoin d’une collection assez complexe de routines qui jonglent avec les demandes entrantes et les traduisent en de multiples changements, dont certains sont élaborés. Koa est conçu pour rendre l’organisation de tout ce travail un peu plus simple. Son secret est qu’il transforme les fonctions de rappel qui dominent normalement JavaScript en un ensemble de fonctions asynchrones qui se déclenchent au moment opportun. Les piles de callback spaghetti imbriquées sont transformées en quelque chose d’un peu plus propre.
Nest
Une autre option pour apprivoiser la complexité du serveur vient de l’équipe Nest, qui propose une architecture remplie de contrôleurs, de tuyaux et de fournisseurs avec quelques gardes, intercepteurs et filtres d’exception jetés pour maintenir l’ordre. Le framework est moderne et prêt à gérer les requêtes GraphQL et les microservices dès le départ.
Drupal, WordPress et Rails
Les frameworks qui sont construits en JavaScript et qui fonctionnent au-dessus de Node.js remplissent le centre psychologique du monde du développement web ces jours-ci. Mais ce peut être une erreur d’ignorer la génération précédente construite sur PHP, une fondation qui est plus rapide que jamais maintenant qu’elle dispose également d’un compilateur juste-à-temps comme JavaScript. Et Ruby et son framework Rails continuent de servir de pierres angulaires à des sites web solides comme le roc.
La dernière génération est aguerrie et bien testée par plus d’une décennie de développement et de travail continus. Il existe des concepteurs sophistiqués qui peuvent créer des thèmes et des habillages pour les applications. Il y a de fortes chances que quelqu’un ait déjà construit les modules avec les fonctionnalités dont vous avez besoin. Donc, avant d’explorer un framework Node.js astucieux, demandez-vous si l’un des anciens ne peut pas déjà faire une grande partie, sinon la totalité, de ce dont vous avez besoin.
Vanilla JS
Vous pourriez y voir une méchante pique ou peut-être une satire du niveau de « Les nouveaux habits de l’empereur », mais il est difficile de contester son succès. Vanilla JS est un site Web qui se vante que son framework est utilisé sur plus de sites Web que « jQuery, Prototype JS, MooTools, YUI et Google Web Toolkit réunis ». Cela peut être vrai ou non étant donné la prolifération de jQuery, mais rions de la brûlure. Le site est également doté d’un joli petit sélecteur qui vous permet de regrouper une archive personnalisée de différents composants tels que Math, DOM, closures ou expressions régulières. Peu importe ce que vous choisissez, le résultat est d’une longueur ahurissante de zéro octet. Essayez de le battre !
Le but de la blague est que parfois, il est judicieux d’utiliser quelques-uns des éléments standard de JavaScript et de sauter les extras. Les bibliothèques et les frameworks comme jQuery ou React ont commencé, en partie, à cause des différences exaspérantes entre les navigateurs. Beaucoup de ces différences ont disparu grâce à la standardisation.
Bien sûr, les partisans de Vanilla JS n’affrontent pas le fait que les fonctions abrégées comme $() ne sont pas seulement pratiques, elles permettent aussi de gagner de la place dans notre propre code. Mais si vous n’allez utiliser le document.getElementById qu’occasionnellement, cela peut ne pas avoir d’importance. Si vous allez juste ajouter quelques fonctions à votre page Web et que ces fonctions feront quelques choses de base, plain vanilla JavaScript peut être le cadre le plus rapide pour vous.