¿Por qué aprender TypeScript?
Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

¿Por qué aprender TypeScript?

Este artículo es una traducción de un post de Kitson Kelly, CTO de SitePen, en el blog de David Walsh.

Si estás metido en la comunidad JavaScript, junto con lo de left-pad, probablemente hayas oído hablar TypeScript. El hecho de que grandes frameworks como Angular o EmberJS lo hayan adoptado le ha proporcionado mucha atención. También me gustaría pensar que, al estar Dojo 2 hecho con TypeScript le da un punto más de calidad al tema, y me gustaría además explicar en parte por qué quizás tú también deberías invertir un poco de tiempo en aprender TypeScript.

Microsoft, ¡buahhh!

Recuerdo el momento en el que se anunció TypeScript por parte de Microsoft, e inmediatamente lo descarté. Normalmente lo hacía con cosas que venían de Microsoft. A mis ojos eran, como muchísimas otras empresas grandes de software, sitios ideales para cargarse la innovación y poner el foco tan solo en desarrollar marca y hacer marketing. En aquel momento era, a duras penas, un director senior de IT por el día, y un comprometido "a escondidas" de Dojo por la noche. Tenía un flujo interminable de empresas de software que aportaban soluciones para mis problemas, sin importar el problema, y superficialmente pensaba que TypeScript era otra forma de atar empresas a la hoja de ruta de Microsoft.

Estaba totalmente equivocado.

Momento fanboy

Un aspecto para entender por qué TypeScript es diferente, en mi opinión, es en base a un poco de ser "fanboy" de Anders Hejlsberg. Cuando empecé a meterme con TypeScript, me di cuenta de que el nombre de Anders Hejlsberg me era vagamente familiar. A finales de los 80 y principio de los 90, yo usaba Turbo Pascal y cuando salió Delphi, migré a él. Me encantaba y predicaba la religión de Delphi a cualquiera dispuesto a escuchar. La programación, en sentido estricto, empezaba a ser algo cada vez menos relevante en mi día a día en el trabajo, pero usaba Delphi como recurso cuando quería montar algo por mí mismo. Recuerdo el día que me enteré que el "malvado" Microsoft le había "robado" el "corazón" de Delphi a Borland para trabajar para Microsoft.

Obviamente, unos pocos años más tarde, empecé a oir hablar de C# y lo descarté al principio por ser una "falsificación de Delphi", pero poco a poco, parecía evolucionar e ir más allá de lo que Delphi aportaba para el mundo. Evidentemente, una gran parte C# debe su existencia a Anders.

Cuando até cabos de que la visión de Anders (y su código) eran partes importantes de Turbo Pascal, Delphi, C#, y ahora TypeScript, me entusiasmé.

No es bonito, pero es lo que hay

No creo que haya muchos desarrolladores (si es que hay alguno) de JavaScript que se levanten por la mañana y digan "qué feliz soy trabajando con JavaScript, es un lenguaje maravilloso". Brendan Eich a menudo se ve a sí mismo en el papel de apologista máximo de JavaScript. JavaScript es un ejemplo perfecto de la Ley de consecuencias no intencionadas. Pero ha explotado, por varias razones. Incluso teniendo grandes detractores y críticos, es una realidad que no se puede negar.

Quizás podemos hacer la comparación con el idioma inglés: es un idioma imperfecto, tiene muchas incoherencias, un montón de dialectos de los cuales solo un subconjunto se puede considerar "globalmente entendido", y muchísimas personas en verdad no lo usan bien. El idioma universal debió haberse pensado mejor, y debería haber sido mucho más racional y estructurado, pero yo no hablo esperanto, ¿y tú?. No nos vamos a librar del inglés jamás.

Imaginemos por un momento que pudiésemos añadir un poco de marcado al inglés, para organizar el idioma un poco mejor. Podríamos tomar el inglés y opcionalmente aplicarle unas normas. Quizás algo como marcado, que te permite meter encabezados y enlaces y bloques de código, todo sin romper el lenguaje subyacente. ¿Suena bien no? Eso es TypeScript.

No entiendo

La naturaleza flexible y no estructurada de JavaScript hizo que fuera "fácil" de programar, pero nunca fue fácil de escalar. Escalar grandes bases de código complejas y mantenibles, escalar para que los demás puedan entender tu código, escalar para que los demás puedan usar tu código. Hoy en día toda la web funciona mediante extensión e interacción, y la barrera más grande que tiene esto es entender la intención.

El primer paso fue parar de escribir código JavaScript inline en nuestro marcado HTML y descomponerlo en archivos separados, más fáciles de mantener, creando funciones:

function myGreatApi(options) {
    /* Con suerte nadie necesitará leer esto */
}

Vale, eso está genial pero aún tendría que crear algo de documentación, para que alguien pudiese usar mi código. Quizás podríamos acordar algo como JSdoc:

/**
  * Mi Gran API hace algo genial, solo úsala
  * @param   {Object} options Algunas opciones que necesito...
  * @returns {Object}         Los resultados de mi gran API
  */
function myGreatApi(options) {
  /* Con suerte nadie necesitará leer esto */
}

Genial, eso está mejor, pero ¿qué pasa si quisiera que el parámetro options fuera opcional? ¿Qué pasa si quiero expresar qué propiedades espero tener en las opciones? ¿Cómo puedo describir qué valor de retorno es mejor...? En teoría podría añadir todo esto a un JSdoc muy complejo, pero en verdad no es fácil de mantener y actualmente no es algo que se pueda forzar, solo documentar (aunque cosas tipo Closure Compiler me pueden dar pistas de que estoy abusando de ello).

¿Y si hubiera alguna manera de describir esto de forma que permitiese a un tercero consumirlo sin saber mucho sobre ello?:

interface MyGreatApiOptions {
  /**
  * La URL de destino para mi API
  */
  target: string;

  /**
  * Traducir de un idioma a otro
  */
  translate?: boolean;
}

interface MyGreatApiResult {
  /**
  * Los encabezados devueltos de la petición
  */
  headers: { [header: string]: string };

  /**
  * La respuesta
  */
  response: string;
}

/**
* Mi Gran API hace algo genial, solo úsala
* @param options Algunas opciones que necesito, quizás, si quieres
*/
function myGreatApi(options?: MyGreatApiOptions): MyGreatApiResult {
  /* ahora nadie tiene que leer esto */
}

Ahora, no solo es que tenga ya una API totalmente documentada, que es ejecutable en tiempo de compilación, sino que como en muchos IDEs está disponible la capacidad de finalización automática de código de modo que el programador pueda recibir información en tiempo real de cómo se consumen las APIs.

He llegado a la conclusión de que TypeScript no solo me permite explicar mis APIs a terceros, sino que me ayuda a estructurar mi código y no me obliga a tener que acordarme de memoria de tantas cosas sobre el código que he escrito. Así me centro más en escribir código productivo y perder menos tiempo revisando código que ya he escrito.

Apertura

Uno de los mejores aspectos de TypeScript es que es abierto y transparente. Es un proyecto de Código Abierto de primera categoría. Los responsables no solo han abierto el código del compilador TypeScript, sino que siguen subiendo el listón y presionan al resto de Microsoft para encontrar formas de abrir el código de las herramientas de las que dependen. Por ejemplo, la herramienta que construye las definiciones de la biblioteca de navegadores se ha hecho Open Source. Además, la inteligencia usada para crear el editor integrado en el navegador, se lanzó como parte del código abierto de Visual Studio Code.

El gancho

Los desarrolladores son un colectivo necesitado y TypeScript al estar desarrollado de forma abierta hace que las personas puedan expresar dichas necesidades.

Además, a veces los desarrolladores confunden código abierto con democracia. El Open Source va sobre ser abierto, permitiendo a los demás ver tu código y tus procesos de desarrollo, y ser transparente sobre las decisiones que tomas y por qué. No significa que porque "necesitas algo de verdad" se vaya a incluir. TypeScript ha expresado sus objetivos de diseño, que suponen un gran punto de referencia para la toma de decisiones concernientes a qué dirección va a tomar el lenguaje.

TypeScript (aún) no tiene el concepto de plugins de transformaciones, lo cual lo diferencia de cosas tipo Babel. Puedo ver cómo dicha funcionalidad podría saciar bien a los desarrolladores necesitados, incluso casi puedo ver cómo puede ser un tiro en el pie para un lenguaje que hace lo que puede para ayudar a los desarrolladores a no escribir "mal" código. Actualmente encontramos dentro de la comunidad de Babel transformaciones mal escritas y mal mantenidas que provocan todo tipo de problemas.

TypeScript es aún relativamente joven y está creciendo día a día, pero en mi opinión ha crecido bajo un gran proceso de gobierno y en la buena dirección. TypeScript 2.0 introdujo cambios sustanciales pero que seguían manteniendo la promesa de hacer escalar JavaScript. Dichos cambios incluyen que se ha rescrito la forma en la que se analizan los tipos en el flujo del código, y una funcionalidad opcional que empieza a tratar con los errores lógicos que se producen en torno a la flexibilidad que da JavaScript con las cosas que son undefined o null.

A pesar de su juventud, TypeScript sigue siendo maduro para su edad. Siendo un súper-conjunto de JavaScript, no está reinventado la rueda: está construyendo sobre un lenguaje que, para lo bueno y lo malo, potencia la web. Si unimos a esto que las partes implicadas tienen mucha experiencia en la construcción de lenguajes y tirando de la experiencia colectiva al ser abierto, ha acelerado mucho el hecho de que esté ya en producción ahora.

Finalmente...

Si no le has echado un vistazo a TypeScript, espero haberte convencido de que es algo que merece un poco de tu tiempo. Personalmente creo que forma parte de un gran cambio cultural en Microsoft, pero incluso si no es tan importante para ti, se puede evaluar en base a sus propios méritos. Tiene a algunas de las mejores mentes trabajando para hacer escalar a JavaScript y el equipo detrás está procediendo de una forma abierta y transparente. Al adoptar la realidad de JavaScript y construir sobre ella, en mi opinión TypeScript está transformando el lenguaje común de la web, para mejor.

Nota campusMVP: TypeScript es el lenguaje que se usa para desarrollar Angular, y el que se utiliza principalmente a la hora de desarrollar en este framework. En nuestro curso sobre Angular también se enseñan los fundamentos de este prometedor lenguaje.

campusMVP campusMVP es la mejor forma de aprender a programar online y en español. En nuestros cursos solamente encontrarás contenidos propios de alta calidad (teoría+vídeos+prácticas) creados y tutelados por los principales expertos del sector. Nosotros vamos mucho más allá de una simple colección de vídeos colgados en Internet porque nuestro principal objetivo es que tú aprendas. Ver todos los posts de campusMVP

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.


Comentarios (3) -

Eduardo Padilla
Eduardo Padilla

Hola CampusMVP, alguna referencia donde se pueda empezar de Cero con Typescript? gracias.

Responder

Hola Eduardo:

En la propia página del lenguaje tienen una documentación súper-completa:

https://www.typescriptlang.org/

Saludos.

Responder

Mauricio Arias
Mauricio Arias

Ey, que buen artículo, me gustaron las analogías usadas. Entiendo la posición que plantean, aunque considero que todo no debe ser tan maravilloso, algunas cosas tuvieron que ser forzadas para ser productivo al corto plazo.

En una próxima oportunidad pueden hablar de las desventajas.

!Un saludo!

Responder

Agregar comentario