Why Typescript?
La respuesta más adecuada desde luego sería: ¿Y por qué no?.
No es de extrañar que cada nuevo producto introducido en el mercado del desarrollo de software sea puesto a prueba por toda la comunidad y posteriormente criticado (positiva o negativamente), consiguiendo así que el resto se acabe posicionando como defensores o detractores del mismo.
Así pues, dentro de la comunidad JavaScript, Typescript no iba a ser menos… pero realmente, lo que el lector desea saber en resumidas cuentas es… ¿Es algo bueno o malo? ¿Qué me aporta y que me resta? Para ello debemos de tener en cuenta muchos factores, los cuales conseguirán que en base a nuestras necesidades, pueda ser una herramienta útil o un complemento innecesario.
¿Qué es Typescript?
Hay quienes promueven el hecho que Typescript es un lenguaje de programación, lo cual desde mi punto de vista, no es una verdad en toda regla, puesto que nuestro código debe ser transpilado a Javascript para su ejecución. Personalmente prefiero quedarme con la propia definición que dan sus creadores afirmando que “es un superset de javascript”, el cual permite (entre otras virtudes) añadir tipado.
A pesar de esto, debemos de tener en cuenta que, con el próximo lanzamiento de Deno, es muy probable que Typescript tome aún más fuerza (Ver post de Daniel Ramos), ya que, el propio creador de Node.js, Ryan Dahl, ha defendido que el hecho de no elegir un lenguaje tipado para este, fue un completo error por su parte y se ha encargado de cambiarlo en este nuevo proyecto.
¿Por qué surge?
Aquellos que llevan tiempo trabajando en proyectos grandes, con un gran número de desarrolladores usando Javascript saben por experiencia que el carecer de tipado, sumado a la flexibilidad a la hora de definir propiedades para los objetos es un arma de doble filo.
Por un lado nos permite hacer lo que queramos sin casi ninguna restricción, pero… ¿y si el compañero o nosotros mismos no somos lo suficientemente responsables como para usar esta característica correctamente o cometemos un typo? ¿Cómo velamos por la integridad del código? O ¿Cómo facilitamos la comprensión del código a cualquier nuevo integrante del proyecto si carecemos de estructuras de datos fuertemente definidas?
Typescript surge para dar respuesta a todas estas cuestiones. Cuando trabajamos con datos modelados sabemos que una clase va a tener determinados atributos, va a estar definido explícitamente en el código y no vamos a tener que especular sobre su composición.
¿Dónde usarlo?
Puede ser usado en proyectos tanto backend como frontend. Sin embargo si nos fijamos en otras características, podemos darnos cuenta de que el usar este “lenguaje” no es mero capricho, sino una solución a una necesidad.
En proyectos de backend es una excelente opción puesto que al tratarse de la capa más abstracta del software, nos ayudará a modelar y definir determinadas reglas en el desarrollo, obligando a los programadores a comprometerse con el contrato especificado en el código, y no da la libertad de tomar decisiones de diseño tan a la ligera.
Como contraparte, en frontend, se suele escuchar muy a menudo que los ficheros generados por la transpilación del código son más pesados que si se hubieran realizado manualmente en Javascript.
Esto puede sonar un argumento bastante sólido para descartar su uso en nuestros proyectos, pero… ¿realmente esto es tan relevante? Desde mi punto de vista, la experiencia de usuario en descargar 30Kb de más puede ser prácticamente insignificante, cuando garantizamos que la experiencia de desarrollo ha sido mucho más productiva. Esto sin contar que estamos protegidos contra determinados errores, sin tener que haber programado validación alguna.
¿Quién lo mantiene?
Desde luego, saber quien es la comunidad que está detrás de un proyecto, es de vital importancia a la hora de determinar si es una buena elección o no, ya sea para recibir soporte, como para que este evolucione y sean corregidos errores de versiones anteriores.
Al frente de este proyecto se encuentra una gran potencia como es Microsoft, que ha sido su principal desarrolladora, pero también muchos otros como Angular, Ionic y Vue (este último a partir de la versión 3) que de manera oficial se han sumado al carro y se encargan de usar y mantener esta herramienta.
Además cabe mencionar la comunidad de usuarios que está detrás de él, los cuales trabajan de forma altruista en generar y mantener los tipos de las librerías más comunes de Javascript.
Además de los tipos agregados a la librerías, existe un macro repositorio llamado DefinetlyTyped, donde se hospedan gran parte de las definiciones de tipos utilizados en Typescript.
¿Alternativas?
Pero Typescript no es la única herramienta existente con esta finalidad, existen otras herramientas que merecen su atención como son: PureScript o ReasonML.
Por desgracia no es del ámbito de este artículo hablar sobre ellas, aunque si tener en cuenta que existen más opciones a la hora de decantarnos por una solución.
¿Qué nos aporta?
Desde mi punto de vista uno de los factores más importantes y menos mencionados es la semántica. Cuando te enfocas en controlar el dominio de una aplicación, la semántica del código es imprescindible, y desde luego un tipado sólido ayuda a ello. Para entender esto veamos el siguiente ejemplo:
Perfecto, tenemos un código donde recuperamos un personaje y le decimos que corra… ¿Qué podría fallar? o mejor dicho… ¿Qué no podría fallar?
Primero, estamos suponiendo que el id, va a ser un string,con el que recuperaremos nueva instancia de un character… y que el personaje va a tener un método run.
Y ¿qué pasaría si, por ejemplo, el id, es un número?, ¿o si se trata de un tipo propio? ¿Qué pasaría si no devuelve un character? o peor aún ¿Qué pasaría si nuestro personaje no implementase run? Nos hemos basado en supuestos porque es nuestro happy path.
¿Y si nosotros definimos lo siguiente?
En primer lugar hemos definido que id no va a ser cualquier string, sino uno que cumple el tipo characterId en segundo lugar, la firma del método, nos obligará a usar dicho tipo, y nos devolverá un Hero que perfectamente podría ser una extensión de Character, esto daría pie a afirmar que los héroes nunca huyen y por tanto, no implementa la función run sino que en su lugar implementa saveTheDay(). Y ESTO ES INCUESTIONABLE.
Cuando agregamos semántica, no damos pie a suposiciones, independientemente a que utilicemos malos nombres en nuestro código, además de librarnos de tener que realizar comprobaciones de tipado.
¿Qué nos quita?
Por supuesto el tener que usar tipos nos resta flexibilidad a la hora de desarrollar y nos obliga a definir interfaces que se adapten constantemente a nuestras necesidades, pudiendo incluso ralentizar nuestro desarrollo.
Supongamos un caso real:
Quiero envolver los hijos que le paso a un componente propio de React, para crear un Carrousel:
Tal y como se hace en Javacript, bastaría con acceder a this.props.children en nuestro componente carrousel e iterarlo con un map. Pero es justo aquí donde se encuentra el problema.
Los typings de React, nos indican que children es del tipo ReactNode y no implementa map, con lo cual estamos perdidos.
O no… la forma más sencilla de solucionarlo es tipar nuestras props, sobrescribiendo los tipos de React de la siguiente manera:
Con esto ya tendríamos el problema solucionado, aunque con la dificultad adicional de agregar este tipo de restricciones cuando las encontrásemos.
Malos usos — any
Cabe destacar que uno de los tipos más “divertidos” es el tipo any, el cual es un tipo genérico que admite cualquier tipo.
Su uso en el proceso de desarrollo puede sernos útil, ya que podemos centrarnos en la funcionalidad que queremos desarrollar, olvidando, por ejemplo, los tipos devueltos por la librería que queremos consumir.
Sin embargo, una vez avanzamos, deberíamos cambiar este any, por el tipo correspondiente, ya que de no ser así, estaremos perdiendo las principal virtudes de Typescript y consiguiendo que nuestro código transpilado ocupe más, sin ninguna funcionalidad.
Malos usos — optional
De la misma manera, podemos definir que una propiedad es opcional haciendo uso de la siguiente notación:
Lo cual puede ser altamente interesante para nuestro modelado. Pero no por ello debemos definir TODAS nuestras propiedades como opcionales. El uso de estas características debe ser acotado a determinadas propiedades, bien justificadas, ya que de no ser así volveríamos al caso ya anteriormente mencionado donde no tenemos la certeza de que la propiedad en cuestión exista.
Conclusión
Desde mi punto de vista, es cierto que hay una leve curva de aprendizaje, y que el código transpilado no es tan óptimo como si lo hiciéramos de forma manual, pero en la mayoría de los casos, ganamos más desde el punto de vista de la calidad del código, su semántica y mantenibilidad, que lo que nos restan estos factores.
No obstante, no siempre tenemos por qué usarlo, si tenemos un proyecto con un tiempo de vida limitado, o si se lo que queremos es realizar un simple spike, es muy probable que al usar Typescript estemos pecando de usar sobreingeniería.
Con todo ello, no quiero decir que estoy en contra del uso de Javascript plano, ni que aquellos que no usen Typescript no son dignos de mi reconocimiento, al contrario, es de mayor valor saber cuando aplicar una herramienta y cuando no.
¿Y a vosotros? ¿Qué os parece esta herramienta? ¿Qué opináis del tema?
Si no queréis abrir un debate público, podéis poneros en contacto conmigo a través de mis redes sociales de Twitter y LinkedIn:
