La razón de la existencia de TypeScript es tener un compilador y un lenguaje que pueda aplicar tipos mejor que el Javascript estándar. Cualquier Javascript regular es TypeScript válido, sintácticamente . Eso no significa que el compilador deba estar completamente satisfecho con él. Vanilla Javascript a menudo contiene código que es problemático en términos de seguridad de tipo. Eso no significa que el código TypeScript no sea válido , pero es exactamente la razón por la que TypeScript existe y es exactamente el trabajo del compilador señalarle esos problemas.

Los idiomas como tales siguen siendo sub/superconjuntos entre sí.

Teorema: TypeScript no es ni un subconjunto ni un superconjunto de JavaScript.

Prueba:

Cuando decimos que el idioma A es un subconjunto del idioma B, queremos decir que todos los programas A válidos también son programas B válidos.

Aquí hay un programa TypeScript válido que no es un programa JavaScript válido:

 let x: number = 3;

Ha identificado un programa JavaScript válido que no es un programa TypeScript válido:

 var foo = {}; foo.bar = 42;

Factor de complicación 1: TypeScript es casi un superconjunto . TypeScript está destinado a ser casi un superconjunto de JavaScript. La mayoría de los JS válidos también son TS válidos. Lo que JS no es, por lo general, se puede modificar fácilmente para compilar sin errores en TS. En otras palabras, el JS más válido también es un TS válido.

Factor de complicación 2: errores no fatales El compilador de TypeScript genera el código JavaScript que desea a veces, incluso si hay errores. El ejemplo al que hice referencia anteriormente emite este error.

 error TS2339: Property 'bar' does not exist on type '{}'.

pero también este código JS

 var foo = {}; foo.bar = 42;

Las notas de la documentación de TS

Puede usar TypeScript incluso si hay errores en su código. Pero en este caso, TypeScript advierte que es probable que su código no se ejecute como se esperaba.

Creo que podemos llamar a esto una compilación fallida (y, por lo tanto, TypeScript no válido) por las siguientes razones:

1. El compilador parece usar el término warning en el sentido convencional, por lo que también debemos interpretar error en el sentido convencional: un error indica que la compilación falló.
2. La documentación indica que el JavaScript resultante no es necesariamente correcto en cuanto a lo que se pretendía. Una salida incorrecta parece tan mala como (si no peor) que no tener ninguna salida. Ambos deben considerarse fallidos.
3. El compilador de TypeScript sale con un código de estado distinto de cero, lo que convencionalmente indica que el proceso falló de alguna manera.
4. Si llamamos a cualquier programa TypeScript que genere JavaScript como "válido", entonces tendríamos que llamar válido al siguiente programa TypeScript, porque un punto se compila en la cadena vacía después de emitir errores:

 .

Factor de complicación 3: TS acepta archivos JS: el compilador de TypeScript puede pasar archivos que terminan en .js (consulte la documentación del compilador para --allowJs ). En este sentido, TypeScript es un superconjunto de JS. Todos los archivos .js se pueden compilar con TypeScript. Esto probablemente no es lo que las personas que visitan esta pregunta quieren preguntar.

Creo que complicar el factor 1 es a lo que se refiere Anders Hejlsberg. También podría justificar el marketing engañoso en la página de inicio de TypeScript. Las otras respuestas han sido víctimas del factor de complicación 2. Sin embargo, el consejo general dado en las otras respuestas es correcto: TypeScript es una capa sobre JavaScript diseñada para avisarle cuando hace algo mal. Son diferentes herramientas para diferentes propósitos.

No. En otras respuestas, creo que la razón técnica se ha explicado bien, pero noto un ejemplo que podría servir inmediatamente como una contradicción con el reclamo en la pregunta (semántica diferente):

 // In TypeScript function f<A>(a: A) { return a; }; console.log(f<Function>(f)); // <-- This line. It will print the function f since it is an identify function that in this case takes self and returns self.

Comparando con el siguiente ejemplo de JavaScript

 // In JavaScript function f(a) { return a; }; console.log(f<Function>(f)); // <-- This line. This is VALID JavaScript

A primera vista, podría pensar que debería haber un error de sintaxis para el ejemplo de JavaScript. SIN EMBARGO, una vez que lo examine de cerca, notará que en realidad la línea se ejecuta como

 console.log((f < Function) > f); // Evaluate to false

que es completamente válido en JavaScript. Básicamente, esto significa que la misma línea de código resultó en 2 interpretaciones completamente diferentes en JavaScript y TypeScript, por lo tanto, un contraejemplo a la pregunta.