Alternativas a TypeScript

es Ashley Claymore y trabajo como ingeniero de software en Bloomberg. He estado usando TypeScript durante seis años, lo que significa que he podido ver cómo ha evolucionado. También he contribuido a TypeScript y soy delegado de TC39. Entonces, ¿cuáles son algunas de las alternativas? Tenemos Clojure, tenemos Flow y también tenemos Hagel. Es posible que las personas estén más familiarizadas con el compilador de Clojure como optimizador de JavaScript, y eso se debe a que hace un buen trabajo optimizando JavaScript. Proyectos como React, que utilizan Flow como verificador de tipos, también utilizan Clojure para optimizar el código. Clojure también tiene un verificador de tipos y admite tanto JS doc como este comentario de tipo más minimalista que estoy mostrando aquí. Hasta donde pude ver, no hay un servidor de lenguaje Clojure que muestre los errores de forma interactiva, en su lugar se ejecuta el compilador de manera más tradicional. Desafortunadamente, solo tengo unos pocos minutos, no voy a tener tiempo para profundizar más en Clojure, pero si estás interesado, por favor, échale un vistazo. Bien, aquí hay un gran bloque de código y no te preocupes por intentar leerlo. Lo importante que estoy tratando de mostrar es que en este fragmento completo, es sintácticamente válido en los tres, Hagel, Flow y TypeScript. Esto nos dice que todos tienen una apariencia y sensación similar, pero divergen y durante el resto de esta charla, lo que voy a hacer es darte una idea de cómo son diferentes entre sí. Por ejemplo, en Flow y Hagel, tienen restricciones de tipo genérico. Utilizan dos puntos en lugar de la palabra clave extends. También tienen este operador de interrogación de unión de prefijo y también permiten que se emitan nombres de parámetros en los tipos de función. Flow principalmente y Hagel exclusivamente utilizan sus tipos de utilidad incorporados cuando se realiza la manipulación de tipos en lugar de tener una sintaxis adicional dedicada para hacer eso. Y luego, estos tipos de utilidad se implementan directamente en sus compiladores. Si comparamos eso con el enfoque de TypeScript, donde casi todos los tipos de utilidad son alias de la forma sintáctica de hacer esa manipulación de tipos, cosas como los tipos de mapeo y la sintaxis de tipos condicionales. Si creo un diagrama de jerarquía de tipos, eso nos permite comparar algunas diferencias en cómo los sistemas modelan sus tipos. Una vez que Hagel está tomando un enfoque diferente es que no tiene un tipo any. Lo más cercano que puedes obtener es el tipo unknown más seguro. Flow tiene any y su tipo unknown lo llaman mixed en su lugar. Y Flow también llama a su tipo inferior empty en lugar de never. Donde TypeScript tiene tanto un tipo void como un tipo undefined, Flow solo tiene void y Hagel solo tiene undefined. TypeScript también coloca su tipo literal de objeto mucho más arriba que los primitivos, mientras que Flow y Hagel hacen esta distinción más fina entre lo que es un primitivo, un arreglo, una función y qué tipos literales de objetos describen. Tengo un ejemplo de eso que viene. En primer lugar, Flow y Hagel tienen este concepto de que los tipos pueden

está cerrado. Entonces, en este ejemplo, porque solo mencioné la propiedad de ruta, cuando se pasan valores que tienen propiedades adicionales, se considera un error, incluso si no se hace en línea. Si estás de acuerdo en permitir que se pasen propiedades adicionales, debes agregar tres puntos al tipo. Eso nos indica que ahora es un tipo abierto. Este es un ejemplo que viene a continuación. Muestra cómo Flow y Hagel tratan su tipo literal de objeto Estoy pasando una cadena e intentando pasar una matriz a una función donde dije dame algo con una propiedad de longitud. Como desarrolladores de JavaScript, sabemos que se puede acceder a una propiedad de longitud, pero aquí se produce un error. Esto se debe a esa distinción más fina entre estos tipos. Si necesitamos incluirlos, entonces tengo que decir explícitamente todo string o array o function para decir que también espero que estos tipos estén bien. Uno de los grandes puntos de venta es que fluirá los tipos que se pasan a una función desde los sitios de llamada. Esto le permite verificar el código incluso si no tiene una anotación de tipo. Una cosa a tener en cuenta con esto es que cuando agregas una nueva llamada a una función, eso afecta la influencia de las mismas llamadas a esa función en el mismo archivo. Entonces, donde anteriormente estaba inferiendo un tipo de retorno de cadena, ahora está inferiendo un tipo de cadena o número porque he introducido una nueva llamada que pasa un tipo diferente. Hagel también tenía un nombre para poder verificar funciones incluso si no tienen anotaciones de tipo, pero tomaron un enfoque diferente. En cambio, al analizar la implementación de la función, construyó una firma genérica que se puede reutilizar. Otra cosa que vi aquí es que Hagel no permitirá inferir implícitamente la conversión de número a cadena. En cambio, debe ser explícito. TypeScript tomó un enfoque diferente. Si bien puede inferir los tipos de las funciones sin anotaciones, en cambio, se ofrece como una solución rápida en lugar de utilizar esa lógica como parte de la verificación de tipos principal. Y un tema general que sentí cuando estaba mirando estos lenguajes, parece que Flow intenta ser más seguro que TypeScript, y luego Hagel intenta ser más seguro que Flow. Y el enfoque más sólido de Flow y Hagel en la interpretación de tipos puede ser realmente sutil. Por ejemplo, en el tipo que estoy mostrando aquí, Flow y Hagel hacen la distinción técnicamente más sólida entre estos dos tipos, mientras que en muchas situaciones, TypeScript permite usarlos indistintamente porque en muchos casos está bien usarlos indistintamente. Y el objetivo de Hagel de no requerir tantas anotaciones de tipo combinado con este mayor énfasis y enfoque en la seguridad, resulta en una sensación diferente al JavaScript que escribes. Por ejemplo, los literales de matriz se infieren como un doble de longitud fija, no es necesario usar as const. Hagel también informa un error de que no estoy usando el valor de retorno de push, la nueva longitud. Debo usar una expresión void para dejar claro que lo estoy haciendo por un efecto secundario y no estoy interesado en el valor de retorno. Bien. Esa fue una exploración realmente rápida de estas otras herramientas. Espero que lo que haya mostrado sea que aunque todas ellas comienzan con este mismo desafío subyacente de verificar estáticamente JavaScript, todas tienen enfoques únicos y igualmente válidos. Me parece realmente fascinante. Siento que demuestra cuánta creatividad se vierte en estas herramientas. Para mí, personalmente, al mirar esas otras herramientas, me ayudó a comprender mejor TypeScript. Entonces, para las personas que son desarrolladores de TypeScript y no están utilizando estas herramientas, aún creo que vale la pena echarles un vistazo. Espero que también te resulte interesante. Muchas gracias por escuchar.