TypeScript, ¿ahora sí?

Hace unos tres años y medio escribí un post sobre TypeScript en el que explicaba por qué su propuesta no me parecía atractiva en ese momento. Recientemente hemos tenido algo de tiempo libre en mi trabajo del Mundo Real™ y hemos podido dedicarnos a analizar unos cuantos lenguajes que podríamos usar en un futuro no muy lejano para desarrollar aplicaciones web. Uno de ellos ha sido TypeScript y creo que es justo, después de aquel post del 2012, dedicarle otro con mi opinión actualizada.

Ya he dicho alguna vez que al elegir un lenguaje de programación influyen factores externos al propio lenguaje. Estos factores están más ligados al contexto en que se va a usar, por lo que en este post se mezclan algunas cosas más objetivas con otras bastante discutibles.

Lo bueno

TypeScript se ha convertido en bastante potente y que empieza a tener personalidad propia. La sensación que transmitía al principio de ser un intento de llevar C# al browser, aunque sigue presente, ya no es tan grande.

En ello ha influido la evolución de Javascript. Como TypeScript siempre ha sido un superconjunto de Javascript, se ha ido compatibilizando con las nuevas construcciones de ECMAScript 2015. Esto facilita el paso desde Javascript “moderno” hacia TypeScript y resulta agradable.

Desde siempre, la gran característica de TypeScript fueron, como no, los tipos estáticos. Incluso los lleva en el nombre. Para muchos el mero hecho de poder disponer de un sistema de tipos estáticos es suficiente, pero es que además el sistema de tipos del TypeScript actual tiene características que permiten una gran expresividad.

Tenemos, por supuesto, interfaces y clases para que resulte familiar a los usuarios de C# y Java (su público objetivo, no nos olvidemos). Esto estuvo desde siempre. A día de hoy también tenemos un tipado estructural bastante majo (no como C#, que tiene tipado estructural para cosas muy concretas, la posibilidad de utilizar tipos suma y tipos intersección o una curiosa forma de extender tipos.

Desgraciadamente la mayoría del código que he visto en internet se limita a traducir código con un estilo muy C# a TypeScript, por lo que no parece que se le esté sacando demasiado partido a estas características. Vamos, que en general cuesta ir más a allá del sistema de tipos de C# o Java.

El tooling alrededor de TypeScript está razonablemente bien conseguido. Todos los editores medianamente populares tienen plugins para trabajar con él que permiten hacer las cosas básicas: comprobar sintaxis y tipos en tiempo real (o casi real), mostrar documentación, autocompletado, renombrar símbolos, ir a la definición. Se agradece, sin duda. Aunque este tipo de herramientas nos pueda llevar a escribir auténticas aberraciones, también nos ayudan a ser más productivos.

Al final, todas estas características hacen que sea un lenguaje muy accesible, tanto para la gente que viene de Javascript como para la gente que viene de C#/Java. Eso es un punto a favor a la hora de considerar usarlo para proyectos de larga duración, porque debería facilitar futuras incorporaciones al equipo.

Lo no tan bueno

Ha habido cosas que no me han gustado mucho, que creo que son decisiones erróneas o que me han dado un poco de miedo.

Tú código no vive aislado del mundo y muchas de las librerías que vas a utilizar, o mejor dicho, que yo quiero utilizar, están escritas en Javascript. La interoperabilidad entre TypeScript y Javascript es magnífica, pero para poder explotar las partes buenas de TypeScript, necesitas tipos, y las librerías de Javascript que vas a utilizar no incluyen esas definiciones de tipos.

Esto se resuelve con unos preciosos ficheros, las definiciones de tipos, que podemos descargar de distintos repositorios y contienen anotaciones de tipos para las APIs de la mayoría de librerías de Javascript. Si no encontramos lo que necesitamos podemos crearnos nosotros mismos nuestra definición de tipos, pero lleva su tiempo.

Con esto de las definiciones de tipos he encontrado dos problemas.

Uno, que aquí el ecosistema de TypeScript se parece mucho al de Javascript y cambia cada poco tiempo. Ahora la herramienta recomendada para gestionar las definiciones de tipos es typings. Hasta hace poco, se usaba otra herramienta, tsd, que todavía se usa para algunas cosas. Pero no os preocupéis, que en TypeScript 2, que sale este año, todo esto vuelve a cambiar y las definiciones de tipos se distribuirán por npm. ¿A que es divertido?

Dejando eso de lado, que para eso he sobrevivido a Javascript unos cuantos años y estoy acostumbrado, otro problema con las definiciones de tipos es que complica gestionar las versiones de las dependencias que tienes.

En Javascript, si por ejemplo usabas React, React-Router y Material UI, y querías actualizar React, tenías que esperar a que React-Router y Material UI (ambas dependientes de React) se actualizasen primero. Ahora con TypeScript, si quieres usar las definiciones de tipos no sólo tienes que esperar a que se actualicen las librerías, sino también sus definiciones de tipos correspondientes.

De hecho, por lo que he visto hasta ahora las definiciones de tipos suelen ir al menos una versión por detrás de la librería correspondiente. No lo considero un factor crítico porque normalmente cuando desarrollo en Javascript las librerías se me quedan desactualizadas a los 20 minutos, pero si eres un obseso de estar a la última, tenlo en cuenta.

Otra cosa que creo que es un error es la inclusión de soporte para JSX en el propio compilador. Y mira que, como usuario de React, me viene muy bien; pero creo que el lenguaje debería estar por encima de librerías concretas, y si dentro de 4 años React y sus derivados ya no están de moda, no creo que el lenguaje deba cargar con el soporte para esa sintaxis.

Llegado ese caso, todas las opciones son malas: si mantienes el soporte a JSX estás asumiendo un coste de mantenimiento inútil, pero si lo quitas, haces que la gente que lo esté usando no pueda aprovechar características de versiones nuevas.

Lo razonable hubiese sido que el soporte para JSX fuese a través de un plugin o similar, posiblemente aprovechando el plugin de Babel, igual que se hace en Javascript, pero a Microsoft todavía le cuesta eso de no controlar todo.

Y esto nos lleva al tercer punto, el del miedo. Que TypeScript esté desarrollado por Microsoft me genera inseguridad. Hace unos años (no muchos) hubiera sido todo lo contrario y lo hubiera visto como una garantía de continuidad y calidad. En los últimos tiempos lo que me transmiten las deciciones de Microsoft es duda, y no sólo en la parte de desarrollo con cosas como .NET Core, sino también en otras áreas como sistemas operativos o movilidad.

Me da la sensación de que no tienen muy claro lo que quieren hacer y, mucho menos, cómo lo quieren hacer, por lo que temo los bandazos que pueda acabar dando TypeScript si, por ejemplo, deciden dentro de 1 año que va a ser parte crítica de .NET Core y empiezan a llenarlo de cosas raras para que funcione mejor sobre él porque piensan que eso les dará puntos dentro de la comunidad node.js o veté tú a saber qué.

Que Google haya decidido adoptarlo en Angular 2 ayuda un poco a recuperar la confianza. No es que Google sea un claro ejemplo de continuidad y cuidado por sus usuarios, recordad que Angular 2 empezó desarrollándose en Javascript, de ahí pasó a AtScript, y de ahí a TypeScript, pero al menos ya son dos empresas grandes que podrían acabar teniendo interés en que TypeScript siguiera funcionando dentro de unos parámetros razonables.

Otras alternativas

Durante nuestros experimentos con otros lenguajes han surgido varias alternativas que han llamado nuestra atención por un sentido u otro. Personalmente, había lenguajes que me parecían extremadamente más interesantes como (por supuesto) ClojureScript, PureScript o Elm, pero siendo realista, apostar por un lenguaje así supone estar dispuesto a asumir que futuras incorporaciones al equipo sean mucho más complicadas, tanto técnica como económicamente.

Una vez descartados los lenguajes interesantes, había dos opciones más viables.

Kotlin, que es un lenguaje desarrollado por JetBrains (los creadores de IntelliJ y ReSharper) bastante accesible pero con características modernas. Quizá con demasiadas características (a veces parece que están intentando meter soporte a todo lo que se les ocurre sea como seas), pero el factor determinante es que todavía el soporte para compilar a Javascript está en fase experimental.

Flow realmente no es un lenguaje, sino una extensión para Javascript que permite escribir anotaciones de tipos y validarlas de forma estática. Me gustaba la idea de mantener la sintaxis y semántica de Javascript sin casi ningún cambio, pero como pasa con tantos proyectos modernos, no tiene soporte para desarrollar en windows, y a día de hoy eso, por desgracia, sigue siendo fundamental para mi.

Conclusión

Empezaré por algo totalmente subjetivo y personal: TypeScript me parece un lenguaje aburrido. Puede que si llego a trabajar más con él y a exprimir su sistema de tipos me acabe divirtiendo (tengo ciertas esperanzas), pero a día de hoy, programar en TypeScript no me motiva mucho.

Es un lenguaje práctico, que no es poco, y con una curva de aprendizaje suave. En ese sentido, resulta adecuado para proyectos que vayan a perduran en el tiempo y puedan requerir variar la composición del equipo. Debería ser fácil encontrar gente que lo conozca o pueda aprenderlo sin muchos problemas.

¿Lo acabaré usando en producción? No lo sé. Es posible. También depende de cuándo decidiera usarlo. Kotlin y Flow, dos alternativas que no están maduras actualmente podrían servirme dentro de unos meses.

¿Recomendaría invertir tiempo en él? Depende. Aquí mi opinión no ha variado mucho con respecto al post de hace 3 años.

Si ya conoces C# o Java, aprender directamente Javascript te va a exponer a más conceptos nuevos y, además, lo vas a necesitar de todas formas si cuando trabajes con TypeScript. No lo veo como un lenguaje que merezca la pena aprender si no lo vas a usar en un proyecto real. Eso no quiere decir que sea un mal lenguaje, simplemente que me parece un lenguaje más práctico que interesante.


13 comentarios en “TypeScript, ¿ahora sí?

  1. En conclusión TypeScript no merece la pena, lo unico que me motivaria es Angular2 pero la veo dificil, solo espero que google recapacite y quite de alguna manera TypeScript, supongo que tendra el mismo fin que CoffeScript, el problema es que las personas en el mundo de Javascript no son muy pacientes pero si creativas, entonces comeinzan a crear lenguajes y demas herramientas que terminan obsoletas a los 2 años xD.

    Segun google trends lo mejor es Javascript puro

    https://www.google.com/trends/explore#q=%2Fm%2F0n50hxv%2C%20%2Fm%2F0hjc5m0%2C%20%2Fm%2F02p97&cmpt=q&tz=Etc%2FGMT%2B5

  2. Bueno, yo no diría tanto.

    TypeScript tiene ventajas a la hora de desarrollar que pueden ser útiles (incluso muy útiles) en determinados casos.

    De hecho, no había realizado la comparativa en Google Trends, pero es curiosa. Según esa gráfica Javascript, habría caído hasta un 30% de su máximo interés (que fue en el 2004) y TypeScript estaría creciendo enormemente.

  3. Al principio me disgustó mucho la idea de adoptar typescript en mi proyecto (no fue decisión mía). Me costó trabajo adaptarme y pasé bastante tiempo tratando de integrar typescript en una base en javascript. Sin embargo, el esfuerzo ha dejado buenos resultados. Tal vez para aplicaciones medianas y pequeñas el tipado no sea algo crítico, pero cuando escribes un cliente SPA que tiene que funcionar igual que como lo hace una aplicación desktop escrita en Java o .Net, una aplicación con un volumen gigante y con muchas dependencias, ahí Typescript se convierte en un poderoso aliado (sobre todo cuando por el equipo pasan coders que nunca han programado en algo diferente a javascript).

  4. Baldomero dijo:

    Como no tengo Twitter te comento aquí tu “tweet” sobre el “comedoritos”.

    https://twitter.com/gulnor/status/741188018346852352

    La respuesta procede de Forocoches. La expresión “comedoritos” es muy típica para calificar a quienes pasan muchas horas delante del ordenador y lo de “el navajazo” suele ser una coletilla muy habitual.

    El hilo original en FC:

    http://www.forocoches.com/foro/showthread.php?t=4966896

    Comentario:

    http://www.forocoches.com/foro/showthread.php?p=230109749#post230109749

  5. Baldomero dijo:

    Un último matiz sobre el término “comedoritos”. Nació por la costumbre que tienen muchos jugones de ponerse con un videojuego y a su lado algo para comer. Al final se crea un perfil de tipo gordo por la vida sedentaria frente al ordenador y por la alimentación a base de “snacks”.

    Cuando se habla de “comedoritos” la imagen asociada es esta:

    https://i.imgur.com/hPhBtzl.png

    En Forocoches suele ser típico hacer referencia de forma irónica a esta clase de gente con frases como: “hoy… noche épica.. World of Warcraft y DORITOS”.

  6. Me ha servido enormemente este Post para decidirme usar Js en lugar de TypeScript en Angular2, ya que solo por ahora lo quiero para testear el framework, me has ahorrado tiempo.
    Por cierto me gustaria quizas en proximos post ver tu opinion de React y Angular2.
    Muchas Gracias.

  7. Saludos.
    Podria TypeScript compararse al lenguaje Scala ? Es una posibilidad interesante si se utilizan las capacidades funcionales de Javascript con el tipado estatico que aporta TypeScript, sin dar tanta preponderancia a OOP.

  8. Nuevamente Saludos.
    Continuando la idea anterior, quisiera saber la opinion de ustedes sobre la posibilidad de que TypeScript termine siendo más versatil que el propio Java o C#, llegando al nivel de Scala, es decir, incorporando los conceptos de OOP y con fuertes capacidades de implementar el paradigma funcional. De parecerles viable esta idea, TypeScript seria digno de convertirse en un lenguaje de respeto.
    Gracias.

  9. Hola Edwin,

    No conozco scala en profundidad, pero hay cosas de TypeScript que sí me han recordado a Scala, como el tipado estructural. Aún así, yo diría que el sistema de tipos de Scala es más potente que el de TypeScript (aunque insisto que no soy un gran conocedor de Scala).

    Un saludo,

    Juanma.

  10. Estoy actualmente en dos proyectos en typescript y la velocidad de desarrollo a aumentado. En partes donde siempre cometía errores y el editor no me avisaba usando javascript, ahora no sucede gracias a typescript. La comodidad de usar clases, interfaces, etc con tanta facilidad hace que mi código no se vuelva tan lioso. Con Ts me he vuelto limpio programando. Cabe destacar que uso ts en el lado del servidor.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>