¿Qué es TypeScript y por qué lo usaría en lugar de JavaScript? [cerrado]


1697

¿Puede describir cuál es el lenguaje TypeScript?

¿Qué puede hacer que JavaScript o las bibliotecas disponibles no puedan hacer, eso me daría una razón para considerarlo?



Aquí hay algunos pensamientos sobre esto: blog.priceandcost.com/development/…
Jefim

Respuestas:


1300

Originalmente escribí esta respuesta cuando TypeScript todavía estaba fuera de la imprenta. Cinco años después, esta es una descripción general aceptable, pero mire la respuesta de Lodewijk a continuación para obtener más información.

Vista de 1000 pies ...

TypeScript es un superconjunto de JavaScript que proporciona principalmente tipos estáticos opcionales, clases e interfaces. Uno de los grandes beneficios es permitir que los IDE brinden un entorno más rico para detectar errores comunes a medida que escribe el código .

Para tener una idea de lo que quiero decir, mira el video introductorio de Microsoft sobre el idioma.

Para un gran proyecto de JavaScript, la adopción de TypeScript podría dar como resultado un software más robusto y, a la vez, implementable donde se ejecutaría una aplicación de JavaScript normal.

Es de código abierto, pero solo obtienes el inteligente Intellisense a medida que escribes si usas un IDE compatible. Inicialmente, esto era solo Visual Studio de Microsoft (también mencionado en la publicación de blog de Miguel de Icaza ). En estos días, otros IDE también ofrecen compatibilidad con TypeScript .

¿Hay otras tecnologías como esta?

Hay CoffeeScript , pero eso realmente tiene un propósito diferente. En mi humilde opinión, CoffeeScript proporciona legibilidad para los humanos, pero TypeScript también proporciona una legibilidad profunda para las herramientas a través de su escritura estática opcional (consulte esta publicación reciente del blog para obtener un poco más de crítica). También hay Dart, pero es un reemplazo completo de JavaScript (aunque puede producir código JavaScript )

Ejemplo

Como ejemplo, aquí hay algunos TypeScript (puedes jugar con esto en TypeScript Playground )

class Greeter {
    greeting: string;
    constructor (message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}  

Y aquí está el JavaScript que produciría

var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();

Observe cómo TypeScript define el tipo de variables miembro y los parámetros del método de clase. Esto se elimina al traducir a JavaScript, pero el IDE y el compilador lo usan para detectar errores, como pasar un tipo numérico al constructor.

También es capaz de inferir tipos que no se declaran explícitamente, por ejemplo, determinaría que el greet()método devuelve una cadena.

Depuración de TypeScript

Muchos navegadores e IDE ofrecen soporte de depuración directa a través de mapas de origen. Consulte esta pregunta de desbordamiento de pila para obtener más detalles: Depuración de código TypeScript con Visual Studio

¿Quiere saber más?

Originalmente escribí esta respuesta cuando TypeScript todavía estaba fuera de la imprenta. Vea la respuesta de Lodewijk a esta pregunta para obtener más detalles actuales.


103
WebStorm ofrece ahora IntelliSense en TypeScript y es multiplataforma.
Radek

26
El problema con estas herramientas es que nunca obtienes el rendimiento completo de javascript. Sí, proporciona una buena legibilidad, pero el código compilado a veces es muy torpe. Confías en una herramienta de terceros para escribir JavaScript nativo, creo que este no es el camino a seguir, es como transformar un idioma a otro idioma. Querer cambiar un idioma que no es otro idioma para comportarse como otro idioma que te gusta, es estúpido y tonto. ...... (final de la parte 1) ......
Codebeat

56
@Erwinus: ¿Aún programabas con ensamblador?
VikciaR

11
@Erwinus Estás haciendo suposiciones sobre cómo funciona TypeScript. Puede escribir JavaScript simple como TypeScript y hacer que el compilador solo compruebe el tipo de tiempo de compilación. No hay pérdida de rendimiento al hacer eso.
aunque el

41
@Erwinus El objetivo de TypeScript es proporcionar una verificación de tipo de tiempo de compilación. Si no ves el valor en eso, está perfectamente bien. TypeScript ha sido referido como "su primera prueba de unidad". Hay muchos recursos que discuten si la verificación de tipo opcional tiene o no valor, y son más detallados que lo que podemos hacer aquí. No estoy tratando de convencerte de nada, solo corrijo un error.
aunquetretrepo

1054

La relación de TypeScript con JavaScript

TypeScript es un superconjunto mecanografiado de JavaScript que se compila en JavaScript simple: typescriptlang.org .

JavaScript es un lenguaje de programación desarrollado por el Comité Técnico 39 de EMCA , que es un grupo de personas compuesto por diferentes partes interesadas. TC39 es un comité organizado por ECMA : una organización de estándares internos. JavaScript tiene muchas implementaciones diferentes de diferentes proveedores (por ejemplo, Google, Microsoft, Oracle, etc.). El objetivo de JavaScript es ser la lengua franca de la web.

TypeScript es un superconjunto del lenguaje JavaScript que tiene un único compilador de código abierto y está desarrollado principalmente por un único proveedor: Microsoft. El objetivo de TypeScript es ayudar a detectar errores temprano a través de un sistema de tipos y hacer que el desarrollo de JavaScript sea más eficiente.

Esencialmente, TypeScript logra sus objetivos de tres maneras:

  1. Soporte para funciones modernas de JavaScript : el lenguaje JavaScript (no el tiempo de ejecución) está estandarizado a través de los estándares ECMAScript . No todos los navegadores y los tiempos de ejecución de JavaScript son compatibles con todas las características de todos los estándares ECMAScript (consulte esta descripción general ). TypeScript permite el uso de muchas de las características más recientes de ECMAScript y las traduce a los objetivos ECMAScript más antiguos de su elección (consulte la lista de objetivos de compilación en la --targetopción del compilador). Esto significa que puede usar de forma segura nuevas características, como módulos, funciones lambda, clases, el operador de propagación y la desestructuración, mientras sigue siendo compatible con versiones anteriores de navegadores y tiempos de ejecución de JavaScript.

  2. Sistema de tipos avanzado : el soporte de tipos no forma parte del estándar ECMAScript y probablemente nunca se deba a la naturaleza interpretada en lugar de la naturaleza compilada de JavaScript. El sistema de tipos de TypeScript es increíblemente rico e incluye: interfaces, enumeraciones, tipos híbridos, genéricos, tipos de unión / intersección, modificadores de acceso y mucho más. El sitio web oficial de TypeScript ofrece una descripción general de estas características. El sistema de tipoescriptcript está a la par con la mayoría de los otros idiomas escritos y, en algunos casos, podría decirse que es más potente.

  3. Soporte de herramientas para desarrolladores : el compilador de TypeScript puede ejecutarse como un proceso en segundo plano para admitir tanto la compilación incremental como la integración de IDE, de modo que pueda navegar más fácilmente, identificar problemas, inspeccionar posibilidades y refactorizar su base de código.

La relación de TypeScript con otros lenguajes de orientación de JavaScript

TypeScript tiene una filosofía única en comparación con otros lenguajes que compilan a JavaScript. El código JavaScript es un código TypeScript válido; TypeScript es un superconjunto de JavaScript. Casi puede cambiar el nombre de sus .jsarchivos a .tsarchivos y comenzar a usar TypeScript (consulte "Interoperabilidad de JavaScript" a continuación). Los archivos TypeScript se compilan en JavaScript legible, por lo que la migración de regreso es posible y comprender el TypeScript compilado no es nada difícil. TypeScript se basa en los éxitos de JavaScript al tiempo que mejora sus debilidades.

Por un lado, tiene herramientas a prueba de futuro que toman los estándares modernos de ECMAScript y lo compilan en versiones anteriores de JavaScript, siendo Babel el más popular. Por otro lado, tiene lenguajes que pueden diferir totalmente de JavaScript que se dirigen a JavaScript, como CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js y todo un host más (consulte esta lista) Estos lenguajes, aunque podrían ser mejores que el futuro de JavaScript, corren un mayor riesgo de no encontrar suficiente adopción para garantizar su futuro. También es posible que tenga más problemas para encontrar desarrolladores experimentados para algunos de estos idiomas, aunque los que encontrará a menudo pueden ser más entusiastas. La interoperabilidad con JavaScript también puede ser un poco más complicada, ya que están más alejados de lo que realmente es JavaScript.

TypeScript se encuentra entre estos dos extremos, equilibrando así el riesgo. TypeScript no es una opción arriesgada por ningún estándar. Se necesita muy poco esfuerzo para acostumbrarse si está familiarizado con JavaScript, ya que no es un lenguaje completamente diferente, tiene un excelente soporte de interoperabilidad de JavaScript y ha visto mucha adopción recientemente.

Opcionalmente escritura estática e inferencia de tipos

JavaScript se escribe dinámicamente. Esto significa que JavaScript no sabe de qué tipo es una variable hasta que realmente se instancia en tiempo de ejecución. Esto también significa que puede ser demasiado tarde. TypeScript agrega compatibilidad con tipos a JavaScript. Los errores causados ​​por suposiciones falsas de que algunas variables son de cierto tipo se pueden erradicar por completo si juegas bien tus cartas (qué tan estricto escribes tu código o si lo haces depende de ti).

TypeScript hace que escribir sea un poco más fácil y mucho menos explícito por el uso de la inferencia de tipos. Por ejemplo: var x = "hello"en TypeScript es lo mismo que var x : string = "hello". El tipo simplemente se infiere de su uso. Incluso si no escribe los tipos explícitamente, todavía están allí para evitar que haga algo que de lo contrario resultaría en un error de tiempo de ejecución.

TypeScript se escribe opcionalmente de manera predeterminada. Por ejemplo, function divideByTwo(x) { return x / 2 }es una función válida en TypeScript que se puede invocar con cualquier tipo de parámetro, aunque llamarlo con una cadena obviamente resultará en un error de tiempo de ejecución . Tal como estás acostumbrado en JavaScript. Esto funciona porque cuando no se asignó ningún tipo explícitamente y el tipo no se pudo inferir, como en el ejemplo divideByTwo, TypeScript asignará implícitamente el tipo any. Esto significa que la firma de tipo de la función divideByTwo se convierte automáticamente function divideByTwo(x : any) : any. Hay una bandera compilador para no permitir este comportamiento: --noImplicitAny. Habilitar esta bandera le brinda un mayor grado de seguridad, pero también significa que tendrá que escribir más.

Los tipos tienen un costo asociado con ellos. En primer lugar, hay una curva de aprendizaje, y en segundo lugar, por supuesto, le costará un poco más de tiempo configurar una base de código utilizando un tipeo estricto adecuado. En mi experiencia, estos costos valen la pena en cualquier código base serio que comparta con otros. Un estudio a gran escala de lenguajes de programación y calidad de código en Github sugiere que "los lenguajes tipados estáticamente, en general, son menos propensos a defectos que los tipos dinámicos, y que el tipeo fuerte es mejor que el tipeo débil en el mismo sentido".

Es interesante notar que este mismo artículo encuentra que TypeScript es menos propenso a errores que JavaScript:

Para aquellos con coeficientes positivos, podemos esperar que el lenguaje esté asociado, ceteris paribus, a un mayor número de reparaciones de defectos. Estos lenguajes incluyen C, C ++, JavaScript , Objective-C, Php y Python. Los lenguajes Clojure, Haskell, Ruby, Scala y TypeScript , todos tienen coeficientes negativos, lo que implica que estos lenguajes son menos propensos que el promedio a generar confirmaciones de corrección de defectos.

Soporte IDE mejorado

La experiencia de desarrollo con TypeScript es una gran mejora sobre JavaScript. El compilador de TypeScript informa en tiempo real al IDE sobre su rica información de tipo. Esto le da un par de grandes ventajas. Por ejemplo, con TypeScript, puede realizar refactorizaciones de forma segura, como cambios de nombre en toda su base de código. Al completar el código, puede obtener ayuda en línea sobre cualquier función que pueda ofrecer una biblioteca. Ya no es necesario recordarlos ni buscarlos en referencias en línea. Los errores de compilación se informan directamente en el IDE con una línea roja ondulada mientras está ocupado codificando. En general, esto permite una ganancia significativa en productividad en comparación con trabajar con JavaScript. Uno puede pasar más tiempo codificando y menos tiempo depurando.

Existe una amplia gama de IDE que tienen un excelente soporte para TypeScript, como Visual Studio Code, WebStorm, Atom y Sublime.

Estrictos controles nulos

Los errores de tiempo de ejecución del formulario cannot read property 'x' of undefinedo undefined is not a functionmuy a menudo son causados ​​por errores en el código JavaScript. De forma predeterminada, TypeScript ya reduce la probabilidad de que se produzcan este tipo de errores, ya que no se puede usar una variable que el compilador de TypeScript no conoce (con la excepción de las propiedades de las anyvariables escritas). Sin embargo, todavía es posible utilizar por error una variable que se establece en undefined. Sin embargo, con la versión 2.0 de TypeScript puede eliminar todo este tipo de errores mediante el uso de tipos no anulables. Esto funciona de la siguiente manera:

Con las comprobaciones nulas estrictas habilitadas ( --strictNullChecksindicador del compilador), el compilador TypeScript no permitirá undefinedser asignado a una variable a menos que usted declare explícitamente que es de tipo anulable. Por ejemplo, let x : number = undefineddará como resultado un error de compilación. Esto encaja perfectamente con la teoría de tipos, ya undefinedque no es un número. Se puede definir xcomo un tipo de suma numbery undefinedpara corregir esto: let x : number | undefined = undefined.

Una vez que se sabe que un tipo es anulable, lo que significa que es de un tipo que también puede ser de valor nullo undefined, el compilador de TypeScript puede determinar a través del análisis de tipo basado en el flujo de control si su código puede usar una variable de manera segura o no. En otras palabras, cuando verifica que una variable es a undefinedtravés de, por ejemplo, una ifdeclaración, el compilador de TypeScript inferirá que el tipo en esa rama del flujo de control de su código ya no es anulable y, por lo tanto, puede usarse de manera segura. Aquí hay un ejemplo simple:

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

Durante la compilación, el codiseñador de la conferencia 2016 de TypeScript, Anders Hejlsberg, dio una explicación detallada y una demostración de esta característica: video (de 44:30 a 56:30).

Compilacion

Para usar TypeScript necesita un proceso de compilación para compilar el código JavaScript. El proceso de construcción generalmente toma solo un par de segundos dependiendo, por supuesto, del tamaño de su proyecto. El compilador TypeScript admite la compilación incremental ( --watchindicador del compilador) para que todos los cambios posteriores se puedan compilar a mayor velocidad.

El compilador TypeScript puede en línea la información del mapa fuente en los archivos .js generados o crear archivos .map separados. La información del mapa de origen puede ser utilizada por utilidades de depuración como Chrome DevTools y otros IDE para relacionar las líneas en JavaScript con las que las generaron en TypeScript. Esto le permite establecer puntos de interrupción e inspeccionar variables durante el tiempo de ejecución directamente en su código TypeScript. La información del mapa fuente funciona bastante bien, existía mucho antes de TypeScript, pero la depuración de TypeScript generalmente no es tan buena como cuando se usa JavaScript directamente. Tome la thispalabra clave por ejemplo. Debido a la semántica cambiada de la thispalabra clave en torno a los cierres desde ES2015, es thisposible que exista durante el tiempo de ejecución como una variable llamada _this(consulte esta respuesta) Esto puede confundirlo durante la depuración, pero generalmente no es un problema si lo sabe o inspecciona el código JavaScript. Cabe señalar que Babel sufre exactamente el mismo tipo de problema.

El compilador TypeScript puede realizar otros trucos, como generar código de interceptación basado en decoradores , generar código de carga de módulos para diferentes sistemas de módulos y analizar JSX . Sin embargo, es probable que necesite una herramienta de compilación además del compilador de Script. Por ejemplo, si desea comprimir su código, tendrá que agregar otras herramientas a su proceso de compilación para hacerlo.

Hay complementos de compilación de TypeScript disponibles para Webpack , Gulp , Grunt y prácticamente cualquier otra herramienta de compilación de JavaScript. La documentación de TypeScript tiene una sección sobre integración con herramientas de compilación que los cubre a todos. Un linter también está disponible en caso de que desee incluso más verificación de tiempo de construcción. También hay una gran cantidad de proyectos semilla que lo ayudarán a comenzar con TypeScript en combinación con otras tecnologías como Angular 2, React, Ember, SystemJS, Webpack, Gulp, etc.

Interoperabilidad de JavaScript

Dado que TypeScript está tan estrechamente relacionado con JavaScript, tiene excelentes capacidades de interoperabilidad, pero se requiere un trabajo adicional para trabajar con bibliotecas JavaScript en TypeScript. Mecanografiado definiciones son necesarias para que el compilador mecanografiado entiende que las llamadas a funciones como _.groupByo angular.copy, o $.fadeOutno están en las declaraciones informativas ilegales. Las definiciones de estas funciones se colocan en .d.tsarchivos.

La forma más simple que puede tomar una definición es permitir que se use un identificador de cualquier manera. Por ejemplo, cuando se usa Lodash , un archivo de definición de línea única declare var _ : anyle permitirá llamar a cualquier función que desee _, pero luego, por supuesto, también puede cometer errores: _.foobar()sería una llamada legal de TypeScript, pero es, por supuesto , una llamada ilegal en tiempo de ejecución. Si desea un soporte de tipo adecuado y la finalización del código, su archivo de definición debe ser más exacto (consulte las definiciones lodash para ver un ejemplo).

El compilador TypeScript comprende automáticamente los módulos Npm que vienen preempaquetados con sus propias definiciones de tipo (consulte la documentación ). Para casi cualquier otra biblioteca JavaScript semi-popular que no incluye sus propias definiciones, alguien ya ha puesto a disposición definiciones de tipo a través de otro módulo npm. Estos módulos tienen el prefijo "@ types /" y provienen de un repositorio de Github llamado DefinitelyTyped .

Hay una advertencia: las definiciones de tipo deben coincidir con la versión de la biblioteca que está utilizando en tiempo de ejecución. Si no lo hacen, TypeScript podría impedirle llamar a una función o desreferenciar una variable que existe o permitirle llamar a una función o desreferenciar una variable que no existe, simplemente porque los tipos no coinciden con el tiempo de ejecución en tiempo de compilación . Así que asegúrese de cargar la versión correcta de las definiciones de tipo para la versión correcta de la biblioteca que está utilizando.

Para ser honesto, hay una pequeña molestia en esto y puede ser una de las razones por las que no elige TypeScript, sino que opta por algo como Babel que no tiene que tener que obtener definiciones de tipo. Por otro lado, si sabe lo que está haciendo, puede superar fácilmente cualquier tipo de problema causado por archivos de definición incorrectos o faltantes.

Conversión de JavaScript a TypeScript

Se .jspuede cambiar el nombre de cualquier archivo a un .tsarchivo y ejecutarlo a través del compilador TypeScript para obtener sintácticamente el mismo código JavaScript que una salida (si fue sintácticamente correcto en primer lugar). Incluso cuando el compilador TypeScript obtiene errores de compilación, seguirá produciendo un .jsarchivo. Incluso puede aceptar .jsarchivos como entrada con la --allowJsbandera. Esto le permite comenzar con TypeScript de inmediato. Desafortunadamente, es probable que ocurran errores de compilación al principio. Uno debe recordar que estos no son errores que detienen la presentación, como puede estar acostumbrado con otros compiladores.

Los errores de compilación que se obtienen al principio al convertir un proyecto JavaScript en un proyecto TypeScript son inevitables por la naturaleza de TypeScript. TypeScript verifica la validez de todo el código y, por lo tanto, necesita conocer todas las funciones y variables que se utilizan. Por lo tanto, las definiciones de tipo deben estar establecidas para todos ellos; de lo contrario, es probable que se produzcan errores de compilación. Como se mencionó en el capítulo anterior, para casi cualquier marco JavaScript hay .d.tsarchivos que se pueden adquirir fácilmente con la instalación de paquetes DefinitelyTyped. Sin embargo, puede ser que haya utilizado alguna biblioteca oscura para la que no hay definiciones de TypeScript disponibles o que haya rellenado algunas primitivas de JavaScript. En ese caso, debe proporcionar definiciones de tipo para estos bits para que los errores de compilación desaparezcan. Simplemente cree un .d.tsarchivo e inclúyalo en la filesmatriz tsconfig.json , para que siempre lo considere el compilador TypeScript. En él declara aquellos bits que TypeScript no conoce como tipo any. Una vez que haya eliminado todos los errores, puede introducir gradualmente la escritura en esas partes según sus necesidades.

También será necesario trabajar en la (re) configuración de su canal de compilación para obtener TypeScript en el canal de compilación. Como se mencionó en el capítulo sobre compilación, hay muchos buenos recursos disponibles y le animo a que busque proyectos semilla que utilicen la combinación de herramientas con las que desea trabajar.

El mayor obstáculo es la curva de aprendizaje. Te animo a jugar con un pequeño proyecto al principio. Mire cómo funciona, cómo se construye, qué archivos usa, cómo está configurado, cómo funciona en su IDE, cómo está estructurado, qué herramientas usa, etc. La conversión de una gran base de código JavaScript a TypeScript es factible cuando sabe qué estás haciendo. Lea este blog, por ejemplo, sobre cómo convertir 600k líneas a mecanografiado en 72 horas ). Solo asegúrese de tener una buena comprensión del idioma antes de dar el salto.

Adopción

TypeScript es de código abierto (Apache 2 con licencia, consulte GitHub ) y está respaldado por Microsoft. Anders Hejlsberg , el arquitecto principal de C # encabeza el proyecto. Es un proyecto muy activo; El equipo de TypeScript ha lanzado una gran cantidad de nuevas funciones en los últimos años y todavía se planean muchas otras excelentes (vea la hoja de ruta ).

Algunos hechos sobre la adopción y la popularidad:

  • En la encuesta de desarrolladores de StackOverflow de 2017, TypeScript fue el transpilador de JavaScript más popular (noveno lugar en general) y ganó el tercer lugar en la categoría de lenguaje de programación más querido.
  • En el encuesta sobre el estado de js de 2018, TypeScript fue declarado como uno de los dos grandes ganadores en la categoría de sabores de JavaScript (siendo ES6 el otro).
  • En la encuesta de 2019 StackOverlow deverloper, TypeScript subió al noveno lugar de los lenguajes más populares entre los desarrolladores profesionales, superando tanto a C como a C ++. Volvió a ocupar el tercer lugar entre la mayoría de los idiomas más queridos.

25
"El código JavaScript es un código TypeScript válido": en realidad, esto no siempre es cierto. Me refiero a un código como si (1 === '1') {} te da un error en TS y en JS no. Pero la mayoría de las veces, si el código JS está bien escrito, es cierto.
Maciej Bukowski

3
Si ha perdido su valioso tiempo productivo preocupándose por un punto y coma perdido, escribir en Typecript sería un salvavidas.
SoSufi

3
Typings ha quedado en desuso, y la mejor práctica actual es simplemente npm(o yarn) install @types/foo. ¿Puedes actualizar tu respuesta?
Jed Fox

13
TL; DR sería ahorrador en esta respuesta;)
Qback

8
@MaciejBukowski Incluso si TypeScript realmente se queja en este caso, aún obtendrá una salida JS válida (que será el código JS que compiló / transpiló con TypeScript). Por lo tanto, es una "compilación con error", y no TypeScript inválido. Está escrito en la especificación de TypeScript que cualquier código JS válido debe ser un código TS válido.
Pac0

83

TypeScript hace algo similar a lo que less o sass hace para CSS. Son súper conjuntos, lo que significa que cada código JS que escribe es un código TypeScript válido. Además, puede usar las otras ventajas que agrega al idioma, y ​​el código transpilado será válido js. Incluso puede configurar la versión JS en la que desea el código resultante.

Actualmente TypeScript es un súper conjunto de ES2015, por lo que podría ser una buena opción para comenzar a aprender las nuevas funciones js y transpilarlas al estándar necesario para su proyecto.


44
Best TL; DR es la página de TS: "TypeScript es un superconjunto mecanografiado de JavaScript que se compila en JavaScript simple".
Juan Mendes

1
Sin embargo, no responde el "por qué debería usarlo". Aquí el tl; dr sería: 1) Para agregar tipos estáticos opcionales a JavaScript. Los tipos pueden ayudar a detectar errores en el momento de la compilación y documentar mejor su programa. 2) Puede escribir el nuevo JavaScript (ES6 / ES7 / ESnext) y volver a compilarlo en ES5, que es necesario para admitir navegadores antiguos; He elaborado un poco más en tsmean.com/articles/vs/typescript-vs-javascript para aquellos interesados ​​en más de un tl; dr
bersling

1
"El código transpilado será JS válido", y ese es el talón de Aquiles de TypeScript si me preguntas. Significa que no pueden agregar varias funciones muy útiles a JS; más notablemente la verificación de tipo de tiempo de ejecución . Es un poco molesto tener seguridad de tipo de tiempo de compilación solo para perderla por los datos de tiempo de ejecución que se leen desde E / S, o cada vez que su código transpilado se llama inseguro de otro JS.
Jez

44

" Fundamentos de TypeScript " - un video-curso de Pluralsight de Dan Wahlin y John Papa es una muy buena actualización (25 de marzo de 2016) para reflejar TypeScript 1.8, introducción a Typecript.

Para mí, las características realmente buenas, además de las buenas posibilidades para intellisense, son las clases , interfaces , módulos , la facilidad de implementación de AMD y la posibilidad de usar el depurador de Visual Studio Typescript cuando se invoca con IE.

Para resumir : si se usa según lo previsto, TypeScript puede hacer que la programación de JavaScript sea más confiable y más fácil. Puede aumentar significativamente la productividad del programador de JavaScript en todo el SDLC.


99
¿Qué son los SDLC? AMD?
Oooogi

15
@Oooogi, SDLC == Ciclo de vida de desarrollo de software. AMD == Definición del módulo asíncrono. El último es específico de JavaScript, mientras que el primero es bastante genérico en su alcance.
Dimitre Novatchev

2
"Facilidad de implementar AMD, ..." - Leí eso y pensé que era algún tipo de optimización de threadripper o algo así.
jrh

15

Ecma script 5 (ES5) que todos los navegadores soportan y precompilan. ES6 / ES2015 y ES / 2016 llegaron este año con muchos cambios, por lo que para que aparezcan estos cambios hay algo en el medio que debe preocuparse por TypeScript.

• TypeScript es Tipos -> Significa que tenemos que definir el tipo de datos de cada propiedad y métodos. Si conoce C #, mecanografiado es fácil de entender.

• La gran ventaja de TypeScript es que identificamos problemas relacionados con el Tipo antes de pasar a producción. Esto permite que las pruebas unitarias fallen si hay algún tipo de desajuste.


2
¡No todos los años, amigo! ... han cambiado las especificaciones después de una larga espera
Subham Tripathi

... y, esos cambios que puede correlacionar con Microsoft metiendo sus dedos en él. ;-)
Trober

2
@SubhamTripathi Mucho es cada año. ES2015, ES2016, ES2017, y desde ahora hasta que el idioma muera. No fue todos los años, antes de 2015, pero lo es ahora. Busque "Proceso TC39" para obtener más información.
daemonexmachina

1
¿hubo una gran demanda de verificación de tipos en la comunidad javascript? Simplemente no he tenido muchos errores relacionados con la verificación de tipos.
Box y Cox
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.