ReasonML vs TypeScript

bucklescript (5)

¿Cuáles son las compensaciones entre ReasonML ( https://reasonml.github.io/ ) y TypeScript ( https://www.typescriptlang.org/ )?

(solo una nota)

Dejando de lado todos los aspectos prácticos;

La familia de lenguajes ML se basa en una teoría de tipos llamada System-F, que también es utilizada por Purescript y Haskell, por ejemplo.

Typescript carece de una base bien establecida y en su lugar utiliza un nuevo sistema de tipo experimental con muchos bits especiales (ni siquiera estoy seguro de si está "formalizado").

Entonces, en la superficie, el enfoque de TS puede parecer "práctico", pero introduce una mayor complejidad de la necesaria. El sistema F tiene un pequeño número de reglas que conforman el sistema y es muy general, aunque más fácil de razonar sobre la "teoría" de ese TS. . Menos es más.

Además, el esfuerzo puesto en el aprendizaje de System-F es bastante atemporal y se traduce a otros lenguajes más poderosos, como Purescript.

En una aplicación grande, necesitará muchas funciones, que se proporcionan de forma predeterminada en ReasonML: tipos estrictos, validación en tiempo de ejecución si codifica / decodifica JSON, tiempo de compilación rápido, datos inmutables.

En TypeScript deberás agregar:

ImmutableJS + sus tipificaciones.
Validadores en tiempo de ejecución como json-schema + sus tipificaciones. Luego, tendrá que escribir tipos en TypeScript y también definir un esquema en json-schemas. Pueden desincronizarse muy pronto.
Algunos hacks locos para indicar la diferencia si la variable es de un tipo específico (como en los documentos oficiales de TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html , párrafo "Guardias de tipo definido por el usuario") . Estas comprobaciones se realizan utilizando efectos secundarios como a.swim! == undefined. En 6 meses, esta declaración ''si'' contendrá más y más cheques.
Tiene suerte si un paquete que usa tiene definiciones de tipo oficiales y mantenidas. O terminarás con tipificaciones personalizadas.
Si desarrolla una aplicación híbrida en JS + TS, entonces TS Compiler no puede crear un archivo d.ts final agrupado que puede importar en otras partes de su proyecto. Tendrá que escribir archivos d.ts separados, que se agrupan con herramientas como dts-bundle . Si tiene todo en TS, este problema no es aplicable.
Las aplicaciones grandes llevan mucho tiempo para ser compiladas por TypeScript.

Con ReasonML:

Los datos inmutables están en el idioma.
Los validadores de tiempo de ejecución están presentes ( bs-json tiene de forma predeterminada)
La coincidencia de patrones te salva de estos controles locos.
Tienes suerte si el paquete npm que quieres usar tiene enlaces BuckleScript.
N / A.
La compilación de ReasonML es muy rápida.

Hay muchas concesiones, muchas de ellas derivadas de ReasonML que técnicamente solo son OCaml y, por lo tanto, heredan la mayoría de las decisiones de diseño de los 25 años de historia de OCaml de ser un lenguaje compilado de forma nativa con poca consideración por este extraño nicho de JavaScript en la web.

Pero tal como está, creo que la mayor compensación es entre el sistema de tipo flexible y de sonido de ReasonML, y la capacidad de TypeScript para "colar" fácilmente las comprobaciones estáticas integrales en una base de código JavaScript existente.

El sistema de tipos de TypeScript está diseñado explícitamente para que no sea sólido, por lo que mientras te da una mano la mayor parte del tiempo, no podrá darte muchas garantías . Realmente no puedes confiar completamente en el sistema de tipos para tener tu espalda, que es una de las mayores ventajas de tener un sistema de tipo estático adecuado.

TypeScript también está limitado por su decisión de evitar la información de tipo de tiempo de ejecución, que es necesaria para características como la coincidencia de patrones y un beneficio importante de trabajar con datos escritos en ReasonML.

ReasonML, por otro lado, requiere que el límite entre él y el código existente de JavaScript esté explícitamente definido. Los tipos se pueden inferir en cierta medida, pero aún deben determinarse en tiempo de compilación. Esto hace que la interoperación de JavaScript sea más laboriosa, especialmente si el límite se mueve gradualmente a medida que se convierte una base de código JavaScript existente. Tampoco es siempre obvio cómo escribir algunas de las cosas raras que suceden en JavaScript, pero generalmente es posible, y es de esperar solo temporal hasta que todo se haya convertido a ReasonML de todos modos :)

Obviamente estoy sesgado, pero espero que esto no se vea como un claro ganador, al menos porque realmente no lo hay. Este es un importante compromiso, al menos mientras el mundo no sea perfecto.

Hay muchos idiomas hoy en día que se dirigen a JavaScript. La elección de uno de ellos depende de sus necesidades y los idioms que se sienta cómodo.

JavaScript tiene un sistema de tipo dinámico. Algunos desarrolladores prefieren uno estático.

TypeScript o Haxe resuelve esto con un nuevo lenguaje que se escribe de forma estática y solo se transpila a JavaScript.
Flow es un preprocesador de JavaScript que se dirige al mismo problema pero sin la necesidad de aprender un nuevo idioma. Prefiero este enfoque si solo necesitas un tipo de sistema.

Algunos desarrolladores de JS desean más y utilizan más lenguajes de programación funcional (estructuras de datos algebraicos, inmutabilidad, coincidencia de patrones, ...). Muchos lenguajes de programación pueden hacerlo (OCaml, Haskell, ReasonML, F #, Scala, ...).

ReasonML es una sintaxis para OCaml que puede compilarse a nativo o JavaScript a través de BuckleScript. Todo lo que puede lograr con Reason también se puede lograr con OCaml, excepto que la sintaxis de ReasonML acepta JSX. ReasonML puede apuntar fácilmente a la aplicación node.js, a la aplicación react.js o a la aplicación nativa.

TypeScript es fácil de aprender si vienes del mundo Java o C #.

ReasonML es más difícil de aprender si nunca se desarrolló con un lenguaje ML (OCaml o F #)

Mi consejo:

Si solo necesita un sistema de tipo estático, debe considerar TypeScript
Si necesita un sistema de tipos para hacer una aplicación react.js o react-native, debe considerar ReasonML porque ReasonReact es una gran mejora con respecto a react.js
Si necesita un lenguaje de programación funcional que compile a js, debe considerar ReasonML

Son muy diferentes.

ReasonML es un lenguaje distinto de JavaScript que se compila a JavaScript
TypeScript es un superconjunto estricto de JavaScript que se compila hasta JavaScript

Si desea escribir código de seguridad de tipos, ambas opciones son excelentes.

Si desea escribir JavaScript con seguridad de tipos, entonces TypeScript es la opción.
Si desea escribir algún tipo de lenguaje que se compile en JavaScript, ReasonML es una de las muchas opciones. El lenguaje de algunos en el caso de ReasonML es OCAML.

Más

Mi opinión parcial: https://medium.com/@basarat/typescript-won-a4e0dfde4b08