javascript reactjs typescript babeljs flowtype

javascript - flow js vs typescript



Reaccionar-usando TypeScript vs Flow vs? (3)

Actualmente estoy aprendiendo React y creo que lo entiendo bastante bien. Sin embargo, hay una cosa que me ha estado molestando con respecto al desarrollo de aplicaciones robustas de React: ¿qué herramientas usan los desarrolladores para la comprobación de tipos estáticos?

Realmente me gusta TypeScript. Creo que reduce el dolor de desarrollar aplicaciones de JavaScript bastante, gracias a la comprobación de tipos y otras características interesantes. Visual Studio Code también ofrece una terminación de código realmente agradable. Y sé que puedo hacer que funcione con React utilizando typings + DenifitelyTyped .

El caso es que no hay muchos tutoriales sobre el uso de React + TypeScript. Tampoco parece haber muchos artículos sobre cómo desarrollar el uso de este combo. Por otro lado, muchas personas parecen estar usando Flow , que es un proyecto respaldado por Facebook (y supongo que también lo usan).

Me las he arreglado para encontrar una discusión sobre Reddit con pros y contras acerca de cómo reaccionar con React + TypeScript / React + Flow. Sin embargo, para mí, parece ser bastante obsoleto ya que tiene unos 10 meses de edad. Creo que muchas cosas han cambiado desde entonces.

También encontré dos artículos sobre el uso de React + Flow y React + TypeScript . El autor menciona algunos problemas que ha encontrado al usar ambas opciones y concluye que TypeScript es "la mejor apuesta ahora" (noviembre de 2015), especialmente porque el proyecto Flow tiene muchos problemas y recibe poca actividad de desarrollador de Facebook. También menciona que no funciona bien con Babel?

Entonces, supongo que la pregunta sería: ¿Es seguro usar el combo React + TypeScript, o me encontraré con algunas dificultades? ¿Qué hay de Flow? ¿Hay alguna otra herramienta similar que debería revisar? ¿Qué enfoque recomendarías?

Actualización de septiembre de 2017:

Con más de un año de experiencia con el uso diario de TypeScript y jugando con Flow por un tiempo, he llegado a las siguientes conclusiones:

  • TypeScript sigue siendo doloroso de usar hasta el día de hoy. El problema es que el mundo de JavaScript se mueve tan rápido que TypeScript se queda atrás. ¿Estás pensando en usar esa nueva y lujosa característica de la etapa 3 de ES7? No, no puedes. ¿Desea obtener sugerencias de tipo para la última versión de alguna biblioteca? Espera un mes, o dos, tal vez más ...
  • Flow ha recorrido un largo camino, se ha mejorado mucho, puede atrapar algunas cosas que TS no puede. Lo mejor de todo es que finalmente funciona en Windows. Además, hay un gran complemento para el código VS (no tengo idea de por qué tiene solo 3/5 de calificación). Y funciona al 100% con React Native, TypeScript aún no llega al 50%.
  • La mayoría de las veces, no necesitas tipos en absoluto. Toda la tipificación adicional rara vez vale la pena. JS es un lenguaje de tipado dinámico, superarlo :)

TL; DR: Si planeas utilizar cualquier tipo de corrector, te recomiendo usar Flow.

En mi desarrollo de React, tengo un conjunto de Webpack Babel / Webpack / Flow / Mocha bastante complejo y nunca tuve problemas con Flow. Hace un esfuerzo para configurar todo (el paquete web puede ser desalentador al principio), pero luego, simplemente funciona. El flujo es definitivamente el camino a seguir, ya que es una tecnología más estrecha y enfocada y, como tal, es más probable que funcione bien con otras herramientas. Por el contrario, TypeScript intenta ser mucho más que solo una herramienta de verificación de inferencia / tipo estático y, por lo tanto, aporta un bagaje y suposiciones adicionales. So React es una herramienta especializada que hace una cosa bien, mientras que TypeScript es efectivamente un lenguaje en capas sobre JavaScript. Para asegurarse de que Microsoft maneja su punto de inicio, los archivos de TypeScript también tienen una extensión diferente ( .ts lugar de .js ) porque ahora está usando un idioma diferente, ¿ .ts ?

TypeScript utiliza la generación de código para escupir JavaScript, mientras que en Flow las anotaciones simplemente se eliminan, no hay generación de código como tal. En el pasado, las personas de Microsoft que promocionaban TypeScript solían hacer una declaración en el sentido de que la generación de código es "local de archivo" (no recuerdo la terminología exacta utilizada). Se suponía que esto proporcionaría una tranquilidad reconfortante de que el compilador de TypeScript no está haciendo nada demasiado mágico. En cualquier caso, no puedo encontrar esa declaración prominentemente exhibida más. Con Flow no necesita garantías como las que escribe en JavaScript simple (o en cualquier versión de ECMA para la que haya configurado Babel) y las anotaciones, como dije, simplemente se han eliminado.

Sin mencionar que TypeScript proviene de una compañía que se especializa en prácticas técnicas poco éticas y cuestionables (no descarto que TypeScript pueda eventualmente convertirse en la Madre de todos los trucos de Embrace-Extender-Extinguir). No olvidemos que Microsoft hizo todo lo que estaba en su poder para hacer que Javascript fallara, ya que (con razón, si tardíamente) previeron la amenaza que representa, y aún representa, a su sistema operativo defectuoso y su suite de oficina hinchada.

Además, el sistema de tipos de Flow fue mucho más poderoso la última vez que me tomé la molestia de evaluar TypeScript (circa 2015) y fue mucho más fácil aplicarlo incrementalmente o incluso esporádicamente en las fuentes. Para integrar bibliotecas de terceros, flowtyped y es muy raro que necesite complementar las que allí se encuentran con mis propias definiciones.

Finalmente, el hecho de que Angular use TypeScript no significa absolutamente nada ya que Angular no es realmente relevante para nuevos proyectos. Reaccionar ha ganado indiscutiblemente, es hora de seguir adelante.

Me acabo de hacer la misma pregunta (aunque no con React) y encontré los siguientes artículos útiles para evaluar los dos:

El enfoque adoptado por los diseñadores de flujo se siente más funcional con una mejor inferencia de tipo y un mejor enfoque para los nulos. Sin embargo, TypeScript tiene mejor soporte de la comunidad, especialmente con respecto a la extracción de tipos para bibliotecas de terceros a través de http://definitelytyped.org/ que es importante para que los tipos fluyan a través de todo su código para obtener la máxima seguridad posible. TypeScript es creado por Microsoft, que tiene una gran historia en la escritura de compiladores y la evolución de la tecnología en direcciones favorables. Aquí es notable C # y el hecho de que ya están agregando tipos no null (2016-07-11): https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript parece ser la apuesta más segura hoy en día.

Y para aquellos que prueban el uso de TypeScript en una base de código existente, encontré la siguiente configuración en mi archivo tsconfig.json realmente útil para permitir que TypeScript coexistiera muy bien con JavaScript (permitiendo la transición de un archivo a la vez):

{ "compilerOptions": { "allowJs": true, "isolatedModules": true, ... } }

Voy a comenzar esta respuesta diciendo que nunca he usado Flow, así que no puedo decir mucho al respecto. Pero, estamos usando React y TypeScript en el trabajo y funciona muy bien.

Tenemos todos los beneficios que imagino que ya conoce, como refactorización, tipo de seguridad, autocompletado, etc.

Claro, por lo que he visto, la sintaxis de Flow es más limpia que TypeScript, pero puede agregar sus tipos usando TypeScript de forma incremental. Creo que esto es más una cuestión de gusto. Algunas personas prefieren tener el código explícitamente escrito, otros prefieren escribir menos y tienen una inferencia de tipo más fuerte.

Sobre, las tecnologías diría que TypeScript es una apuesta segura, Microsoft está impulsando el lenguaje ( pronto habrá una versión 2 ), Angular también lo está utilizando y hay muchos desarrolladores de Angular. Incluso aquí en SO, la etiqueta TypeScript tiene más de 4K seguidores y es raro tener una pregunta sin respuesta.

El gran problema con TypeScript, al menos para nosotros, es que de vez en cuando, decidimos utilizar un componente o una biblioteca que no tiene las definiciones de tipo, por lo que debemos crearlos nosotros mismos. Pero supongo que esa es una forma de contribuir a la comunidad.