Diferencias entre TypeScript y Dart [cerrado]

Microsoft presentó recientemente TypeScript, un nuevo lenguaje de programación similar a JavaScript. Hace algún tiempo, escuché sobre Dart, un nuevo lenguaje de programación creado por Google para resolver problemas relacionados con Javascript, como el rendimiento, la escalabilidad, etc.

El propósito de ambos idiomas nuevos me parece el mismo. ¿Qué opinas?

¿Los propósitos de los idiomas son los mismos?

¿Cuáles son las diferencias reales sobre ellos?

Citando a Bob Nystrom :

TypeScript parece agradable si le gusta la semántica JS o tiene una gran base de código JS en la que está invertido pero tiene problemas de mantenimiento a escala. Su camino hacia el éxito es mucho más suave ya que (¿en su mayoría?) Es compatible con JS.

Dart está tomando una apuesta más arriesgada. Está más lejos de JS en muchos aspectos, lo que creo que es principalmente bueno como programador diario de Dart, pero hace que la barrera de entrada sea más alta. Pero a cambio de esa barrera de entrada más alta, obtienes:

• Sacudida del árbol
• Getters y setters (aunque supongo que TypeScript los obtendrá eventualmente)
• Sobrecarga del operador
• Alcance de bloque real, sin elevación, sin IIFE s
• Una máquina virtual nativa
• Semántica de igualdad sana
• Ninguna locura de conversión implícita extraña
• Léxico atado a this todas partes
• Mixins
• Anotaciones
• Un sistema de importación
• Operadores de subíndice definidos por el usuario
• Genéricos, con reificación
• Espejos
• Mejores clases de colección
• Una API DOM más limpia

Además, escribe en http://www.reddit.com/r/programming/comments/10rkd9/welcome_to_typescript/c6g37xd :

Estoy en el equipo Dart de Google, así que, naturalmente, lo estoy mirando desde ese ángulo / sesgo. Aquí hay algunas cosas al azar que me llamaron la atención, principalmente comparándolas con Dart. Solo pasé unos minutos hojeando, así que no te tomes nada de esto demasiado en serio ...

Sin genéricos

Supongo que algunos tipos son mejores que ningún tipo, pero es realmente difícil perderlos. TypeScript tiene tipos de matriz incorporados y los tipos de objetos cubren algunos de los casos de uso de tipo "mapa". Pero no poder definir sus propios tipos genéricos es un lastre. Los documentos dicen que cuando se agreguen, los genéricos funcionarán usando el tipo de borrado, que es lo que esperaría dado que es "compilar con el estilo ligero JS", pero eso también puede ser un dolor. Es bueno poder hacer cosas con sus argumentos de tipo en tiempo de ejecución a veces.

Todos los tipos son anulables

Dart es de la misma manera. Me pone triste en ambos casos.

La sintaxis de la anotación de tipo es agradable

Casi todos los idiomas con anotaciones de tipo opcionales (ML, Scala, F #, Kotlin, etc.) van con "postfix después de un:. Dart intenta usar anotaciones de tipo estilo C que causan algunos casos de esquina desagradables. Me gusta lo que TypeScript tiene aquí, especialmente la sintaxis para los tipos de funciones:

function takeCallback(callback : (n : number) => number)
{ ... }

Las interfaces se tipifican estructuralmente, las clases se tipifican nominalmente

Tiene sentido dado que es JavaScript, pero parece bastante bueno. Ser capaz de implementar implícitamente una interfaz es bueno. Pero TypeScript no parece permitirle ir a otro lado: dada una clase, no puede hacer un nuevo tipo que sea compatible con él sin extenderlo concretamente debido a las cosas de la marca. En Dart, gracias a las interfaces implícitas, puedes hacerlo.

El mejor tipo común puede fallar

Eso significa que este es un error de tipo:

[1, true]

Puede sobrecargar en interfaces por firma de parámetro

Esto es realmente genial porque le brinda una forma de tener un flujo de inferencia de tipos más preciso a través de una llamada de función que realiza un cambio de tipo dinámico. Por ejemplo:

interface Doubler {
  double(s : string) : string;
  double(n : number) : number;
}

Con esto, cuando el compilador ve una llamada al doble, puede darle correctamente un tipo de retorno preciso basado en el tipo de argumento inferido. Lo que no estoy seguro es cómo implementar realmente una clase que implemente esa interfaz y haga feliz al verificador de tipos. En realidad, no puede sobrecargar métodos concretos, y mi intento de cinco minutos de hacerlo feliz mediante la verificación dinámica de tipos no pareció funcionar.

Hay una sintaxis dedicada para los tipos de matriz

Tiene sentido ya que no hay genéricos. También es agradable y breve, lo cual es bueno, pero personalmente prefiero los genéricos de uso general a las colecciones de casos especiales.

No hay abatimiento implícito

Una de las características del sistema de tipos más inusuales de Dart es que la compatibilidad de la asignación es bidireccional: puede rechazar sin previo aviso. Aparte del típico caso especial de asignación a / desde cualquiera (dinámico en otros lenguajes), TypeScript no lo permite. Tienes que escribir afirmar. Personalmente, me gusta el enfoque de TypeScript aquí.

Funciones de flecha y esto léxico

Esto es solo maternidad y tarta de manzana. Me gusta. (Dart también tiene esto, y esto siempre está ligado léxicamente).

En general, se ve muy bien. Si desea exactamente la misma semántica de JS (buena y mala) pero también quiere un puñado de tipos, TypeScript parece decente. Es como Closure Compiler pero con una mejor sintaxis.

Si quieres algo que esté más lejos de la sintaxis y la semántica de JS, entonces parece que TypeScript no es eso.

Si bien la pregunta era "¿Son los propósitos de los idiomas los mismos?", La pregunta real es: "¿Cómo podemos mejorar la programación web desde donde estamos?" .

Ambos proyectos intentan hacer esto considerando

• lenguaje de programación (TypeScript hace un paso pequeño pero muy limpio, Dart hace el movimiento más revolucionario que todavía se está moviendo)

• interoperabilidad con el código js existente (transición 0 en TypeScript que compila a js, complicado en Dart, ya que 2 máquinas virtuales se comunican entre sí)

• prácticas de ingeniería de software (solo Dart, componentes web y shadow dom)

En los últimos 3 días me sumergí profundamente en Dart y luego en TypeScript. Mi base de código CoffeeScript fue a las líneas de código de la década de 2000, demasiado para ser manejada con CoffeeScript encantador pero demasiado esponjoso. El problema que enfrenté fue que CoffeeScript carece de características que los lenguajes diseñados para la programación de mediana a gran escala tienen: interfaces, módulos, seguridad de tipo. Pero había una incluso mucho problema más grave con el café y JS: Los js "este puntero" rareza afectado mi cordura y CoffeeScript no ayuda nada aquí.

Así que aquí mis resultados después de 3 días de evaluación y uso:

Dardo

Revisé a fondo el tutorial, leí 1 libro, hojeé el segundo libro y probé las demos. Yo pensé, dardo que es el futuro . Luego intenté migrar mi aplicación a Dart. Fue allí donde mi entusiasmo bajó de 100 a 10. Aquí está la razón:

1. El Editor de Dart es la única forma de programar Dart. Si bien existen complementos para Sublime Text, no proporcionan características como intellisense, finalización de código (corríjame si me equivoco). Sin embargo, el Dart Editor está en calidad pre alfa. Si bien admite cosas mágicas súper frías, como actualizar la página web cuando edita el archivo CSS (! Realmente genial), se cuelga o se bloquea varias veces por minuto. Entonces escribe 5 letras y 2 veces tiene que esperar 2 segundos o 15 segundos entre escribir. Y tenía un proyecto con algunas líneas de código, por lo que no quería esperar lo que sucede cuando hay líneas de 1000. Moví un archivo de una carpeta a otra dentro del Editor de Dart, se bloqueó. Depuracióncon Dart Editor es a primera vista mejor que todas las herramientas de depuración de js que conozco (Chrome es mi elección), pero todavía faltan muchas cosas: sin ventana inmediata (esto hace que la depuración de js sea mucho mejor en este momento), sin relojes.

2. Política y posibilidades de escape : algunos dicen que Apple, MS y Firefox nunca proporcionarán máquinas virtuales Dart. Bueno, no estoy tan seguro, pero al menos para Apple esto parece muy seguro en este momento. Para los demás es más probable que lo contrario. Así que no hay problema, podemos convertir Dart a JavaScript. La forma en que funciona esta integración es realmente excelente, Dart mantiene un stub js que mantiene el código js conectado al Dart Editor, por lo print()que todavía aparece una declaración en Dart Editor, genial. Pero aquí viene el pero: la huella de dicho código convertido es alta. 150kB más o menos (antes de la minificación). No excavé demasiado en el tamaño exacto, así que no me apuntes en esto.

3. Madurez del lenguaje . Además de los problemas demasiado serios con Dart Editor apareciendo en mi cara 3 veces por minuto, también encontré inaceptable que cada fuente sobre el código Dart que encuentre use un Dart diferente. El idioma cambia todos los días. ¿Encontraste una publicación de hace 5 semanas? Está desactualizado. ¿Pruebas las muestras del tutorial de Google? Al menos 1 muestra no se compila desde que cambió una API. Incluso cosas mundanas, como adjuntar un evento a un elemento DOM, están en buen movimiento .

4. La integración con las bibliotecas js existentes es un poco complicada. 2 VM necesitan comunicarse aquí, es complicado.

Como conclusión, no puedes usar Dart en serio a partir de hoy, y sumergirte en él no es demasiado divertido debido a 1 y 3. Ambos puntos desaparecerán con el tiempo. Sobre el punto 2, Google publicó puntos de referencia de rendimiento hace unos días demostrando que su js compilado es mejor que js escrito a mano. Mis cumplidos, buen trabajo. El tiempo de carga aún podría estar retrasado debido al problema de la huella como se dijo. Sin embargo, si el código de la huella se usa en muchos sitios, puede estar disponible en caché y listo, también desaparece.

Entonces: considero que Dart es un gran proyecto, usarlo en este momento conlleva una buena parte del riesgo imprevisible y tomará este año llevarlo a un buen nivel estable.

Mecanografiado

Evaluar TypeScript es muy fácil, lleva 1 o 2 horas y lo sabes todo. Leyendo el documento de especificaciones del lenguaje y un libro corto (TypeScript revelado) revelado, lo sabía todo y comencé a programar. Luego me sorprendió descubrir que las adiciones de TypeScript a JavaScript solo satisfacen todas las necesidades serias que tenía para mejorar la programación de mi cliente . Aquí lo más destacado:

1. Interfaces . La encapsulación y las interfaces me permiten estructurar mi código fácilmente. ¡Perfecto!

2. Estado de clase. . TypeScript permite expresar el estado que las instancias de una clase llevan explícitamente, o mejor lo hace cumplir. Este es un gran paso mejor en comparación con js o café.

3. thisllamada mitigación mitigada . Dentro de las funciones de flecha, TypeScript hace que el thispuntero sea como cualquier ciudadano de comportamiento normal.

4. Editor, Intellisense . TypeScript viene con un 100% de inteligencia superior perfecta que reacciona en el rango de micro o milisegundos como se usa desde Visual Studio cuando se programa C #. También existen encabezados TypeScript para todas las bibliotecas js importantes . Genial genial genial.

5. Experiencia y riesgo . El uso de TypeScript conlleva un riesgo cero, el lenguaje está claramente definido, perfectamente estable, es solo js con azúcar, nada imprevisible.

En realidad, estas mejoras me dan todo lo que necesitaba. Lo único que me gustaría ver en el futuro son las colecciones genéricas. Pero eso es maní.

Entonces, ¿qué pasa con el rendimiento? Si bien me considero un fanático del rendimiento, no creo que haya ningún proyecto que haga la elección de tecnología aquí en función del rendimiento. Ambos están en la liga js.

Si está interesado en el futuro de la programación web, ambos son grandes esfuerzos, TypeScript es mucho más pragmático y utilizable ahora, Dart es un proyecto de laboratorio muy interesante que será utilizable una vez que los editores y depuradores maduros estén disponibles y el alcance de los proyectos sea factible con Dependerá de la política.

En cualquier caso, los 3 días evaluados fueron en su mayoría divertidos y aprendí mucho, si encuentra el tiempo, Dart demora 1 día para TypeScript y 2 horas para dar su propia opinión. Intentalo.

Actualización de octubre de 2014

Ha pasado un tiempo y, a posteriori, parece que la suposición de que TypeScript es la ruta segura y estable era bastante correcta. Acabo de encontrar una declaración (muy) destacada sobre Typecript, Dart y Closure:

He estado interesado en el desafío de la programación web en general durante bastante tiempo. Creo que Google Closure sigue siendo la mejor opción para el desarrollo a gran escala de JavaScript / Web, pero que finalmente será reemplazado por algo que sea menos detallado. Aunque Dart muestra una promesa considerable, todavía estoy consternado por el tamaño del JavaScript que genera. En comparación, si TypeScript se puede traducir directamente a JavaScript que se puede compilar utilizando el modo avanzado del compilador de cierre, entonces podemos tener todos los beneficios de JavaScript optimizado de Closure sin la verbosidad. Además, dado que TypeScript es un superconjunto de JavaScript, creo que sus extensiones de sintaxis tienen la posibilidad de convertirse en el estándar ECMAScript en algún momento,

http://blog.bolinfest.com/2013/01/generating-google-closure-javascript.html

Michael Bolin es un héroe de front end de google (ex) google (ex) desde hace mucho tiempo, también está involucrado en el cierre de google (obtenga su libro sobre Closure).

Google Traceur

La aplicación de Google para vivir ECMA Script 6 hoy es su proyecto Traceur: https://github.com/google/traceur-compiler

En comparación con Typecript, el soporte de herramientas está presumiblemente muy por detrás de hoy. Por el lado positivo, sin embargo, es mucho más rápido adoptar adopciones de lenguaje js futuras demasiado geniales como iteradores o comprensiones.

Flujo de Facebook, Google AtScript

Proporcionar características similares a TypeScript.

"Uno puede preguntarse qué pasa con estas diferentes soluciones de verificación de tipos de JavaScript y qué hacer al respecto. Una buena noticia es que Microsoft, Facebook y Google están colaborando en esto, según Jonathan Turner de Microsoft:

El equipo de TypeScript está trabajando con los equipos de Flow y AtScript para ayudar a garantizar que los recursos que ya han sido creados por la comunidad de mecanografía de JavaScript se puedan utilizar en estas herramientas. Hay mucho que estos proyectos pueden aprender unos de otros, y esperamos trabajar juntos en el futuro y crear las mejores herramientas que podamos para la comunidad de JavaScript. A largo plazo, también trabajaremos para incorporar las mejores características de estas herramientas en ECMAScript, el estándar detrás de JavaScript. "

Artículo de infoq sobre flujo de fb

Citando a Scott Hanselman:

La gente ha comparado TypeScript con Dart. Eso es comparar manzanas con carburadores. TypeScript se basa en JavaScript para que no haya problemas de interoperabilidad JS. Dart es una máquina virtual nativa escrita desde cero. Dart interopera con JavaScript ... pero no es JS. Ni siquiera usa el tipo de número de JavaScript, por ejemplo.

¿ Por qué TypeScript tiene que ser la respuesta a algo?

Tuve que intervenir en esta discusión con mi propio hallazgo últimamente.

1 °: TypeScript

MS ha adoptado un enfoque agradable en el hecho de que puede entrar y salir fácilmente de TS y JS. Principalmente utilizamos AngularJS para nuestro desarrollo y hemos descubierto que, aunque no existe mucha documentación para convertir Angular a TypeScript. Ha sido una buena adición incorporar TypeScript en nuestro flujo de trabajo de desarrollo.

2do: Dardo

Dart es un paso irónico para Google. Tal vez no recuerdan activeX y todas las pesadillas que intentan hacer que una aplicación funcione en otra cosa que no sea el temido IE 5 o IE 6 del día. La EM ha tardado muchos años en recuperarse de esos días.

Dart como lenguaje "conceptualmente" parece intentar combinar algunas características agradables de OOP. Las anotaciones, etc. son un buen pensamiento para Javascript.

El problema es que es difícil imaginar suficiente ancho de banda para crear un nuevo editor, un nuevo lenguaje, nuevas vm en los navegadores, complementos para otros IDE, compilador para convertir a JavaScript (sin tener varios meg de tamaño), convertir o crear nuevas bibliotecas de dardos a reemplace las miles de bibliotecas js actuales, haga que alguien decida polímeros o directivas, convierta el sitio de dartlang para usar dart, esto es lo que puedo pensar fuera de mi cabeza.

El concepto de tratar de usar Dart en cualquier cosa menos una aplicación trivial en este momento es aterrador.

Además de todo esto, ES6 no está muy lejos. ES6 trae muchas características que Dart está tratando de arreglar que existen en ES5. ¿Cuál será la propuesta de valor una vez que ES6 salga a la calle? Al menos en este momento, el único cambio que tiene que hacer en TypeScript una vez que sale ES6 es quizás elegir una compilación diferente para apuntar.

Solo para aclarar que soy una persona pro EM. MS fabrica algunos productos decentes y ha hecho grandes avances para corregir errores pasados ​​con la comunidad OSS. Todavía varío raramente uso algo más que TypeScript de MS.