ReasonML vs TypeScript
Quels sont les compromis entre ReasonML ( https://reasonml.github.io/ ) et TypeScript ( https://www.typescriptlang.org/ )?
De nos jours, beaucoup de langages ciblent JavaScript. Le choix de l’un d’eux dépend de vos besoins et du idiomes avec lequel vous êtes à l'aise.
JavaScript a un système de type dynamique. Certains développeurs préfèrent un statique.
TypeScript ou Haxe résout ce problème avec un nouveau langage typé statiquement qui ne transpile qu'en JavaScript.
Flow est un préprocesseur JavaScript qui cible le même problème mais sans avoir besoin d'apprendre une nouvelle langue. Je préfère cette approche si vous n’avez besoin que d’un système de types.
Certains développeurs JS en veulent plus et utilisent des idiomes de programmation plus fonctionnels (structures de données algébriques, immuabilité, correspondance de modèle, ...). De nombreux langages de programmation peuvent le faire (OCaml, Haskell, ReasonML, F #, Scala, ...).
- ReasonML est une syntaxe pour OCaml qui peut être compilé en langage natif ou en JavaScript via BuckleScript. OCaml permet également d’atteindre tout ce que vous pouvez réaliser avec Reason, à l’exception de la syntaxe ReasonML qui accepte JSX. ReasonML peut facilement cibler une application node.js, une application react.js ou une application native.
TypeScript est facile à apprendre si vous venez du monde Java ou C #.
ReasonML est plus difficile à apprendre si vous n’avez jamais développé avec un langage ML (OCaml ou F #)
Mon conseil:
Si vous avez juste besoin d'un système de types statique, vous devriez considérer TypeScript.
Si vous avez besoin d'un système de types pour exécuter une application react.js ou react-native, vous devez envisager ReasonML, car ReasonReact représente une amélioration considérable par rapport à react.js.
Si vous avez besoin d’un langage de programmation fonctionnel qui compile en js, vous devez envisager ReasonML.
Il existe de nombreux compromis, dont beaucoup découlent de ReasonML, qui est techniquement juste d'être OCaml et hérite donc de la plupart des décisions de conception issues des 25 années d'expérience d'OCaml dans un langage compilé de manière native avec peu d'égard pour cet étrange créneau JavaScript sur le Web.
Mais, dans l'état actuel des choses, je pense que le compromis le plus important concerne le système de types souple et bien conçu de ReasonML, ainsi que la capacité de TypeScript de "glisser" aisément des contrôles statiques complets dans une base de code JavaScript existante.
Le système de types de TypeScript est explicitement conçu pour ne pas être sonore. Ainsi, même s'il vous donnera un coup de main la plupart du temps, il ne pourra pas vous en donner beaucoup garanties. Vous ne pouvez vraiment pas vraiment faire confiance au système de types pour avoir votre dos, ce qui est l’un des plus grands avantages d’un système de types statique correct.
TypeScript est également limité par sa décision d'éviter les informations de type à l'exécution, ce qui est nécessaire pour des fonctionnalités telles que la correspondance de modèle et un avantage majeur de l'utilisation de données typées dans ReasonML.
D'autre part, ReasonML exige que la limite entre lui-même et le code JavaScript existant soit explicitement définie. Les types peuvent dans une certaine mesure être déduits, mais ils doivent toujours être déterminés au moment de la compilation. Cela rend l’interopérabilité JavaScript plus laborieuse, en particulier si la limite se déplace progressivement à mesure que la base de code JavaScript existante est convertie. Il n’est pas toujours évident non plus de savoir comment taper quelques-uns des éléments étranges contenus dans JavaScript, mais c’est généralement possible et, espérons-le, temporaires, jusqu’à ce que tout soit converti en ReasonML de toute façon :)
De toute évidence, je suis partial, mais j'espère que cela ne semblera pas être un gagnant clair, du moins parce que ce n'est pas le cas. C'est un compromis majeur, du moins tant que le monde n'est pas parfait.
Dans une grande application, vous aurez besoin de nombreuses fonctionnalités, fournies par défaut dans ReasonML: types stricts, validation à l'exécution si vous encodez/décodez JSON, temps de compilation rapide, données immuables.
Dans TypeScript, vous devrez ajouter:
- ImmutableJS + ses typages.
- Les validateurs d’exécution aiment json-schema + ses typings. Ensuite, vous devrez écrire des types dans TypeScript et également définir un schéma dans json-schemas. Ils peuvent devenir désynchronisés très bientôt.
- Quelques astuces délirantes pour faire la différence si la variable est d'un type spécifique (comme dans la documentation officielle de TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html , paragraphe " Gardes de type défini par l'utilisateur "). Ces vérifications sont effectuées à l'aide d'effets secondaires tels que a.swim! == non défini. Dans 6 mois, cette instruction "if" contiendra de plus en plus de contrôles.
- Vous avez de la chance si un paquet que vous utilisez a des définitions de type officielles et gérées. Ou vous allez vous retrouver avec des typages personnalisés.
- Si vous développez une application hybride dans JS + TS, TS Compiler ne peut pas créer de fichier d.ts final groupé que vous pouvez importer dans d'autres parties de votre projet. Vous devrez écrire des fichiers d.ts séparés, qui sont regroupés par des outils tels que dts-bundle . Si vous avez tout dans TS, alors ce problème n'est pas applicable.
- Les applications volumineuses prennent beaucoup de temps pour être compilées par TypeScript.
Avec ReasonML:
- Les données immuables sont dans la langue.
- Les validateurs d'exécution sont présents ( bs-json les a par défaut)
- La correspondance de modèle vous évite ces contrôles fous.
- Vous avez de la chance si le package npm que vous souhaitez utiliser possède des liaisons BuckleScript.
- N/A.
- La compilation de ReasonML est très rapide.
(Juste une note)
Mettre de côté tous les aspects pratiques;
La famille de langages ML est basée sur une théorie de type appelée System-F, également utilisée par Purescript et Haskell.
TypeScript manque d'une base aussi bien établie et utilise à la place un nouveau système de type expérimental avec de nombreux bits spéciaux (je ne suis même pas sûr qu'il soit "formalisé").
Donc, à première vue, l'approche de TS peut sembler "pratique", mais elle introduit plus de complexité que nécessaire. Le système F comporte un petit nombre de règles qui le composent et il est très général, mais plus facile à raisonner à propos de la "théorie" de TS. Moins est plus.
En outre, les efforts consacrés à l'apprentissage de System-F sont plutôt intemporels et se traduisent par d'autres langages plus puissants, tels que Purescript.
Les sont très différents.
- ReasonML est un langage distinct de JavaScript qui se compile en JavaScript
- TypeScript est un sur-ensemble strict de JavaScript compilé en JavaScript
Si vous voulez écrire du code typesafe, ces deux choix sont excellents.
Si vous voulez écrire du typeafe en JavaScript , alors TypeScript est l'option.
Si vous voulez écrire avec un style quelconque compilé en JavaScript, alors ReasonML est l’une des nombreuses options. Le langage dans le cas de ReasonML est OCAML.
Plus
Mon opinion biaisée: https://medium.com/@basarat/TypeScript-won-a4e0dfde4b08
Raison: ML vient avec une première école fonctionnelle, si vous êtes dans cet état d'esprit, c'est la voie à suivre. Considérant que TypeScript peut faire fp et a également un bon support de la communauté. Presque toutes les bibliothèques populaires ont des typages TypeScript. Je préfère utiliser fpts ( https://github.com/gcanti/fp-ts/blob/master/README.md ). Il fournit tous les avantages de fp dans TypeScript, y compris la vérification à l'exécution. Bien que le type constructeur soit un gros raté en ts. Choisissez ts si vous êtes d'accord pour vivre avec.