Cet article a été initialement publié en mai 2018 par Pedro Rolo et mis à jour en mai 2020 par Andre Santos.
Quand on pense à Raison ML, le fait qu'il soit soutenu par Facebook ne dit pas tout. Il s'agit d'une technologie qui a évolué au cours des deux dernières années et qui a beaucoup de potentiel, non seulement en raison de l'influence des outils JavaScript, mais également du point de vue du compilateur vers le code natif.
Dans cet article, j'examinerai de plus près sa genèse et la manière dont d'autres technologies, comme React, BuckleScript ou OCaml, ont façonné son développement.
Raison ML est la nouvelle technologie qui Facebook utilise pour développer des applications React et en faire la promotion en tant que version futuriste de JavaScript (ES2030) ils disent).
En bref :
Le style de programmation de React est beaucoup plus proche de la programmation fonctionnelle que de la programmation orientée objet. Il n'est donc pas surprenant de découvrir que le premier prototype React n'a pas été implémenté dans JavaScript, mais dans ML standard plutôt.
Cependant, alors que le prototype commençait à mûrir, son auteur, Jordan Walke, a décidé de le porter en JavaScript et de continuer à partir de là. Il n'y avait pas de transpileurs matures vers JavaScript et, à l'époque, le monde n'était pas prêt à accepter un langage et un style de programmation aussi peu courants.
En conséquence, React est devenu populaire en tant que technologie liée au langage de programmation JavaScript.
Malgré ce succès au sein du Écosystème JavaScript, certaines personnes ont commencé à sentir qu'il se passait quelque chose dans les coulisses. D'autres projets connexes, tels que Redux, Orme et Purescript - a commencé à gagner en popularité, rapprochant ainsi l'état d'esprit de la communauté des racines initialement fonctionnelles et typées statiquement de React.
Cela a fait croire à Facebook qu'il pourrait être faisable et pratique de rapprocher React de ses racines.
Finalement, ils ont découvert qu'une grande partie du travail préparatoire était déjà prête pour eux...
Certaines entreprises développent des interfaces utilisateur critiques qui, en utilisant des langages dynamiques ou à typage progressif, pourraient représenter des pertes insupportables.
Bloomberg est l'une de ces entreprises. C'était pour Bloomberg selon laquelle Hongbo Zhang travaillait et expérimentait le moteur d'exécution JavaScript, lorsqu'il s'est rendu compte qu'il n'était pas difficile de porter le compilateur OCaml en JavaScript et de l'exécuter sur le navigateur.
La réalité était que le compilateur OCaml était déjà très modulaire. Il n'a pas été très difficile de remplacer son backend générateur de code natif par un backend générant du code javascript. Avec un tel backend, il était même possible de compiler le compilateur OCaml en JavaScript, hébergeant ainsi automatiquement le compilateur BuckleScript et l'exécutant dans le navigateur.
BuckleScript est né et, mieux encore, il a été publié par Bloomberg en tant que logiciel open source.
Il est important de noter que le compilateur OCaml original avait déjà fait l'objet de plusieurs décennies de développement et d'optimisations effectuées par le Institut national de recherche en informatique et en automatique (INRIA). C'était l'un des compilateurs les plus rapides disponibles pour un langage de type aussi complexe.
Si Facebook avait l'intention de rendre l'écosystème React typé statiquement, BuckleScript était certainement un bon candidat. Ils semblaient croire que JavaScript, avec sa célèbre syntaxe frisée, était en grande partie responsable du succès de React.
Cependant, ils n'ont pas été assez naïfs pour simplement utiliser BuckleScript avec sa syntaxe OCaml. Ils préfèrent a conservé la sémantique d'OCaml, le Backend BuckleScript et autant qu'ils le pouvaient grâce à Syntaxe JavaScript.
Afin de conserver la syntaxe JavaScript, ils ont créé un analyseur supplémentaire, en gérant une nouvelle langue appelée Raison ML.
On peut dire que c'est Reason ML est simplement OCaml avec une syntaxe frisée semblable à celle de JavaScript.
Le résultat est étonnamment similaire à JavaScript. Au point que certains codes JavaScript peuvent être traités directement par le compilateur, comme s'il s'agissait de ReasonML, avec tous les avantages d'un compilateur typé statiquement et sans aucun changement de code.
Outre le travail sur le langage et le compilateur lui-même, Facebook a également consacré quelques efforts à développement d'un wrapper ReasonML autour de son framework React, avec une fonctionnalité supplémentaire.
Ça s'appelle Raison de la réaction. Cela facilite les choses pour mélanger des composants JavaScript React avec des composants Reason dans la même application ReactJS ou Reason.
Il convient de noter que React Reason n'est pas simplement un wrapper autour de React. Il fournit également certaines fonctionnalités prêtes à l'emploi qui étaient auparavant fournies avec des bibliothèques externes, telles que Redux et immuable.
Redux est un gestionnaire d'État très populaire parmi les projets React. En termes simples, il permet d'organiser la logique du domaine d'application sous la forme d'un ensemble de fonctions réductrices composées, destinées à exprimer comment l'état de l'application doit être transformé en événements externes (tels que les interactions utilisateur).
Lorsque vous utilisez ReasonML, nous n'avons plus besoin de Redux.
Les composants sans état ReactReason sont déjà dotés du concept d'un réducteur intégré, destiné à résoudre les problèmes que Redux avait l'habitude de résoudre.
Les fonctionnalités qui étaient auparavant fournies par Immutable sont implémentées au niveau du langage.
Les opérations ReasonML (et OCaml) sont immuables par défaut, évitant ainsi les coûts cognitifs et de performances liés à l'utilisation d'une bibliothèque externe.
Il y a quelque temps, j'ai écrit sur la langue Elm. Eh bien, ReasonML et Elm ne sont pas si différents l'un de l'autre.
Analyser leurs différences en profondeur dépasse le cadre de cet article, mais, en résumé, ils découlent d'une position différente quant à la pureté fonctionnelle et au niveau de maturité des deux projets.
Vous trouverez ci-dessous un résumé tabulaire de la correspondance et des différences entre leurs caractéristiques :
Traits communs
Différences
Comme vous pouvez le constater dans le tableau ci-dessus, il est indiqué que ReasonML peut être compilé pour différentes cibles, y compris le code natif. Cela peut être fait en utilisant la couche de syntaxe ReasonML avec le compilateur OCaml d'origine restant, y compris le backend en code natif d'origine.
Il y a beaucoup de potentiel ici. Permettant éventuellement de partager le code de Reason entre le backend et le frontend ou même de compiler le backend en code natif.
L'application phare de ReasonML est Facebook Messenger, qui était à l'origine une application ReactJS qui a été progressivement migré vers ReasonML. De plus, l'adoption de ReasonML va au-delà des projets de Facebook et de nombreuses autres entreprises l'utilisent. Certains d'entre eux sont mentionnés dans la liste Page de documentation de ReasonML.
ReasonML semble être une nouvelle itération, dans le cadre des mêmes efforts, visant à intégrer un langage fonctionnel typé statiquement dans l'écosystème JavaScript.
Néanmoins, l'orientation prise par ce projet et ses bailleurs de fonds semble bien plus prometteuse tant du point de vue marketing que technologique.
Il peut tirer parti des outils et de la syntaxe détendue de JavaScript tandis que en s'appuyant sur le travail effectué pour OCaml, sans oublier qu'il est soutenu par Facebook. En outre, il est possible de accéder à différentes plateformes et environnements grâce à BuckleScript.
Bien que ReasonML ne soit pas la première et certainement pas la dernière à tenter d'atteindre ces objectifs, elle se présente comme une tentative de niveau professionnel, en essayant de satisfaire le goût du grand public.
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
Développeur de rails avec plus de 10 ans d'expérience dans diverses technologies. Je m'intéresse à la programmation fonctionnelle.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
