En 2017-2019, hubo un aumento significativo en TypeScript. Esto sucedió por razones obvias. Hay mucho bien en este idioma. Casi la mitad
de los encuestados
del Estado de JavaScript de 2018 ya han probado TypeScript y planean escribir en él en el futuro. TypeScript es bastante popular, pero ¿vale la pena usarlo en proyectos de software a gran escala?
En este material, se hace un intento bastante estricto, basado en los indicadores numéricos y la experiencia práctica del autor, para analizar el efecto del uso de TypeScript en el desarrollo de grandes proyectos.
Acerca del crecimiento de TypeScript
TypeScript es uno de los lenguajes de más rápido crecimiento. Actualmente, es el lenguaje líder de los compilados en JavaScript. Aquí están los datos de TypeScript de Google Trends.
Datos de tendencias de Google 2014-2019 sobre la dinámica de popularidad de TypeScriptLa siguiente es la
información de GitHub, que refleja el interés de los programadores en el trabajo en el desarrollo de varios lenguajes de programación.
Datos de GitHub sobre el crecimiento de los lenguajes de programación en términos del número de contribuyentesLos anteriores son indicadores muy impresionantes que indican la creciente popularidad de TypeScript, que no debe subestimarse. Pero debe tenerse en cuenta que TS aún está lejos de ser reconocido como el lenguaje líder del ecosistema de JavaScript. Si el ecosistema de JavaScript se compara con el océano, TypeScript será una gran ola en este océano. Aquí hay una comparación de JavaScript (línea roja) y TypeScript (línea azul) según Google Trends.
Datos de Google Trends 2014-2018 sobre la dinámica de la popularidad de JavaScript y TypeScriptY aquí hay
información de GitHub sobre los principales lenguajes de programación utilizados para crear repositorios en 2008-2018.
Datos de GitHub sobre la cantidad de repositorios creados usando varios lenguajes de programaciónPuede ver que, por la cantidad de repositorios, TypeScript no se encuentra entre los cinco idiomas principales.
Cabe señalar que en 2018 hubo un punto de inflexión en la historia de TypeScript, y en 2019 este lenguaje se utilizará en muchos proyectos reales. Si usted es un desarrollador de JavaScript, entonces, en tales condiciones, simplemente no tendrá otra opción. La decisión de usar TypeScript en un proyecto en el que tiene que trabajar ya se tomará sin tener en cuenta su opinión. No necesita tener miedo de aprender y usar TypeScript.
Sin embargo, si usted es quien decide qué lenguaje usar en un proyecto, entonces debe tener una comprensión realista de las fortalezas y debilidades de TypeScript. Al tomar decisiones, deberá comprender si la elección de TypeScript afectará bien o mal al proyecto.
Mi experiencia sugiere que TypeScript tiene sus pros y sus contras, pero no se puede decir que su uso, en general, tenga un impacto positivo en los proyectos. TypeScript atrajo a muchos desarrolladores, y muchas cosas están conectadas con este lenguaje que a mí, que lo he probado en la práctica, me gusta mucho. Pero tienes que pagar por todo.
Antecedentes
Llegué a JavaScript desde el mundo de los lenguajes estáticamente escritos, como C / C ++ y Java. Al principio, fue difícil para mí adaptarme a la escritura dinámica adoptada en JavaScript, pero tan pronto como me acostumbré, me sentí como una persona que llegó a la salida de un túnel largo y oscuro y vio la luz. La escritura estática tiene muchas características positivas, pero lo mismo se puede decir sobre la escritura dinámica.
En los últimos años, me he sumergido periódicamente en el desarrollo de TypeScript. Como resultado, obtuve más de un año de práctica en TypeScript. Lideré varios equipos grandes usando TypeScript como su idioma principal. Esto me permitió evaluar el impacto de TypeScript en el desarrollo de proyectos grandes y comparar proyectos similares con proyectos similares que usaban JavaScript normal.
En 2018, las aplicaciones descentralizadas podrían
despegar . La mayoría de estas aplicaciones usaban contratos inteligentes y soluciones de código abierto. Al desarrollar aplicaciones para Internet de valor, los errores en los programas pueden costar dinero a los usuarios. Ahora más que nunca, es importante escribir código confiable. Como estos proyectos suelen ser de código abierto, pensé que lo que usamos en el desarrollo de TypeScript es bueno, ya que esto facilitará que otros equipos de TypeScript trabajen con nuestras soluciones y, al mismo tiempo, esto garantiza la compatibilidad nuestro código con proyectos que usan JavaScript.
Durante el uso práctico de TypeScript, comencé a comprender mejor las ventajas y desventajas de este lenguaje. También me quedó claro qué tipo de elección podría tener TypeScript en un proyecto de software. Lamento decir que la experiencia con TypeScript no fue tan exitosa como quería. Si TypeScript no se mejora significativamente, entonces no elegiré este lenguaje para otro proyecto a gran escala.
Fortalezas de TypeScript
TypeScript, a la larga, todavía me parece un desarrollo positivo. Quiero amar este lenguaje, y todavía definitivamente me gustan algunas de sus características. Espero que los desarrolladores de TypeScript y sus defensores vean críticas constructivas en este material y no ataques infundados en este lenguaje. Los desarrolladores de TypeScript pueden corregir algunas de sus deficiencias, y si lo hacen, puedo repetir mi análisis de la efectividad de este lenguaje y obtener diferentes resultados.
La escritura estática puede ser muy útil porque ayuda a documentar funciones, hace que el código sea más fácil de entender y reduce la sobrecarga cognitiva del programador. Por ejemplo, generalmente encuentro que el sistema de tipo Haskell funciona, que no requiere demasiado tiempo y esfuerzo, conveniente, discreto. Pero a veces, incluso el sistema de tipo flexible de Haskell y sus tipos de clase superior dificultan el trabajo. Por ejemplo, intente escribir un transductor con Haskell o TypeScript. Esto no es fácil de hacer, y quizás el resultado sea ligeramente peor que su equivalente sin tipo.
Me gusta el hecho de que las anotaciones de TypeScript, si interfieren, pueden ser opcionales. Me gusta el hecho de que TypeScript utiliza la tipificación estructural, y que hay cierto soporte para la inferencia de tipos (aunque hay muchas oportunidades de mejora en esta área).
TypeScript admite interfaces que son reutilizables (a diferencia de las declaraciones de tipo incorporadas). Las interfaces se pueden usar de diferentes maneras para anotar API y firmas de funciones. Una sola interfaz puede tener muchas implementaciones. Las interfaces son una de las mejores características de TypeScript y me gustaría que apareciera algo similar en JavaScript normal.
Una de las fortalezas de TypeScript es su kit de herramientas. Por ejemplo, el uso de un editor adecuado (como Atom o Visual Studio Code), para el cual se crean complementos TS de alta calidad, pone a disposición del desarrollador las mejores herramientas en el ecosistema de JavaScript. Los desarrolladores de otros complementos deberían estudiar los complementos TS y pensar cómo, utilizando las ideas incorporadas en ellos, pueden mejorar su desarrollo.
Análisis de rendimiento de TypeScript
Ahora voy a evaluar TypeScript para varios indicadores, estableciendo calificaciones en el rango de -10 a 10. Esto lo ayudará a comprender mejor qué tan bueno (o malo) puede tener TypeScript en proyectos grandes.
Si la puntuación en el indicador excede 0, esto indica el impacto positivo de TypeScript en el proyecto. Si el puntaje es menor a 0, esto indica un impacto negativo. Un valor de calificación de 3-5 puntos indica un efecto bastante fuerte. 2 puntos indican exposición promedio. 1 punto es un efecto relativamente débil.
Los números con los que continuaré operando son difíciles de medir con precisión. En mis evaluaciones, seré, hasta cierto punto, subjetivo. Pero traté de hacer estas estimaciones para que revelen las ventajas y desventajas del uso de TypeScript en proyectos reales de la manera más realista posible.
Todos los proyectos que analicé, dando calificaciones, contenían más de 50 mil líneas de código. Fueron el resultado del trabajo de varios programadores durante varios meses. Uno de estos proyectos está basado en Angular 2, usó TypeScript. Se comparó con un proyecto similar escrito usando Angular 1 y JavaScript normal. Todos los demás proyectos se basan en React y Node usando TypeScript. Se compararon con proyectos similares que usaban JavaScript simple. Algunos indicadores, como la densidad de errores, se estimaron solo aproximadamente. Todos los equipos que trabajan en proyectos consistieron en desarrolladores de TypeScript experimentados y novatos. Todos los miembros de dichos equipos tuvieron la oportunidad de interactuar con mentores más experimentados que los ayudaron a adaptarse en el campo del desarrollo de TypeScript.
Debido al pequeño tamaño de la muestra, los datos objetivos que tengo son demasiado heterogéneos, hay demasiado ruido en ellos, por lo tanto, en base a ellos, es imposible hacer ciertos juicios objetivos que puedan hacerse con base en cifras suficientemente precisas y sin arriesgar demasiado cometer un gran error Un proyecto de JavaScript mostró una densidad de errores en la producción que fue un 41% menor que un proyecto TypeScript comparable. En otra comparación, un proyecto TypeScript mostró una densidad de error 4% menor que un proyecto JavaScript comparable. En este caso, es obvio que el número de errores que alcanzaron la etapa de lanzamiento del producto se ve mucho más afectado no por el uso de TypeScript en el proyecto, sino por la presencia o ausencia de otras medidas para garantizar la calidad del código. Esto distorsiona los indicadores hasta tal punto que resulta imposible usarlos.
Una gama tan amplia de indicadores objetivos condujo al hecho de que decidí no usarlos, centrándome en el ritmo de implementación de las oportunidades del proyecto y en las observaciones que indican las áreas del ciclo de vida del proyecto en las que pasó la mayor parte del tiempo. A continuación, analizando los indicadores, hablaremos de esto con más detalle.
Como mi análisis tiene un fuerte componente subjetivo, debe considerar la posibilidad de imprecisiones en la interpretación de los indicadores (esto se refleja en el diagrama). Pero las conclusiones generales de este análisis pueden proporcionar una imagen realista de lo que puede esperar al usar un proyecto TypeScript.
Análisis de rendimiento de TypeScriptYa puedo escuchar las objeciones con respecto a las bajas calificaciones de los beneficios de TypeScript y, francamente, no puedo rechazar por completo estas objeciones. TypeScript, de hecho, le da al programador algunas características muy útiles y poderosas. No puede haber ninguna duda sobre esto.
Para comprender la razón de las calificaciones positivas comparativamente bajas y raras en mi análisis, debe comprender bien con qué estoy comparando TypeScript. Esto no es "solo JavaScript", sino JavaScript y herramientas diseñadas para un desarrollo efectivo en este lenguaje.
Considere los indicadores que se muestran en el diagrama.
▍ Herramientas para desarrolladores
Toolkit es mi característica favorita de TypeScript, que es probablemente la mayor ventaja práctica de usar este lenguaje. Gracias a las herramientas de alta calidad, se reduce la carga cognitiva en el desarrollador. A su disposición hay consejos sobre los tipos de interfaces, en el proceso, en tiempo real, se detectan posibles errores. Si no sucediera nada como esto al desarrollar en JavaScript simple usando buenos complementos, le daría a TypeScript una calificación positiva más alta. Pero en nuestro caso, 0 puntos es algo que ya puede usar al programar en JavaScript, es decir, con el que estamos comparando TypeScript, ya está en un nivel bastante alto.
La mayoría de los defensores de TypeScript no parecen entender muy bien con qué compite TypeScript. El punto es que la elección de herramientas no es una decisión sobre si usar TypeScript o JavaScript sin ninguna herramienta auxiliar. Se trata de elegir entre TypeScript y todo el rico ecosistema de herramientas de desarrollo de JavaScript. Las herramientas de detección de errores y finalización de código para JavaScript común proporcionan el 80-90% de lo que generalmente se consideran fortalezas de TypeScript. Esto sucede, por ejemplo, cuando se usan herramientas para
completar el código, herramientas para
generar tipos y
linters . Al usar el sistema de inferencia de tipos y al aplicar los parámetros de función predeterminados que aparecieron en ES6, el desarrollador tiene a su disposición consejos que son muy similares a los que están disponibles cuando se trabaja en código TypeScript con anotaciones de tipo.
Un ejemplo de autocompletado de código JS regular con inferencia de tiposHonestamente, si usa la configuración predeterminada para proporcionar sugerencias de tipo, entonces no es necesario que anote el código TypeScript. Esta es una técnica excelente para reducir el número de construcciones de sintaxis auxiliares, que son una de las desventajas de TypeScript.
Las herramientas utilizadas para escribir código TypeScript son quizás un poco mejores, se ven más holísticas, pero todo esto no es suficiente para dar a TypeScript una calificación mucho más alta y para cubrir las deficiencias de este lenguaje.
▍ Documentación API
Otro beneficio importante de TypeScript es su mejor documentación de API. De hecho, podemos decir que la documentación de la API siempre corresponde al estado del código fuente. Incluso se puede generar documentación basada en el código TypeScript. Para este indicador TypeScript, también se podría dar una calificación más alta si, al programar en JavaScript, no se puede usar algo como
JSDoc ,
Tern.js y muchas herramientas para generar documentación. Personalmente, no soy un fanático de JSDoc, por lo que TypeScript en mi análisis de este indicador es muy apreciado.
Cabe señalar que, incluso utilizando la mejor documentación integrada en el código del mundo, uno no puede prescindir de la documentación real, por lo tanto, es justo decir que las capacidades de TypeScript tienen más probabilidades de expandir las capacidades de compilación de documentación existentes en lugar de reemplazarlas.
▍ Tipo de seguridad
Al comparar el tipo de seguridad de TS y JS, como resultó, no es posible revelar una diferencia especial. Los proponentes de TypeScript a menudo hablan de los beneficios de la seguridad de tipos, pero no se puede decir que la
seguridad de tipos reduce significativamente la densidad de errores en la producción. Este es un punto importante, ya que el uso de la revisión de código y TDD tiene un impacto serio en la resolución de problemas (solo el uso de la técnica
TDD reduce los errores en un 40-80%). Si combina TDD con un análisis de la arquitectura de los proyectos, con la verificación de especificaciones y con revisiones de código, puede lograr una reducción de más del 90% en la densidad de errores. Muchas de estas técnicas (TDD en particular) pueden ayudarlo a encontrar los mismos errores que se pueden detectar con TypeScript, así como muchos errores que TypeScript no puede detectar.
Aquí damos algunos cálculos de
este estudio . El máximo teórico de errores "disponibles públicamente" que TypeScript puede detectar es de aproximadamente el 15%. Los errores "públicos" son errores que sobreviven a la fase de desarrollo del proyecto y terminan en un repositorio público.
El estudio mencionado monitoreó errores que se conocían de antemano. Esto incluía saber qué líneas de código se cambiaron para corregir errores, mientras que el problema y su posible solución se conocían antes de escribir el código. Esto significa que incluso el conocimiento de la existencia de errores no permitió, usando TypeScript, detectar el 85% de los errores "públicos".
¿Por qué TypeScript no puede detectar tantos errores? ¿Por qué digo que el 15% de los errores detectados son el máximo teórico de TypeScript? Para empezar, vale la pena señalar que, de acuerdo con el estudio en cuestión, los errores en las especificaciones conducen a aproximadamente el 78% de los errores en los repositorios públicos de GitHub. La incapacidad de formular claramente las especificaciones de los programas o la incapacidad de implementar correctamente las especificaciones conducen al tipo de error más común. Esto lleva automáticamente al hecho de que la mayoría de los errores en los proyectos de software TypeScript no se pueden detectar o prevenir. Los autores del estudio, entre otras cosas, identifican y clasifican errores que TypeScript no detecta. Aquí hay un gráfico de barras con información sobre tales errores.
Errores que no son detectados por TypeScriptEl ejemplo "StringError" es un error que ocurre si se usa una cadena donde se necesita una cadena, es decir, no se producen errores en los tipos, pero el contenido de esta cadena en sí causa un error (por ejemplo, puede haber una URL incorrecta). Mediante el análisis estático, puede identificar algunos de estos errores examinando el contenido de las cadenas y utilizando descripciones de este contenido. Pero esto solo dará la posibilidad de corregir una pequeña fracción de un pequeño porcentaje de errores. Como resultado, estamos diciendo que es poco probable que TypeScript pueda detectar más del 15-18% de los errores.
Aquí puede parecer que el 15% ya es bastante. ¿Por qué TypeScript no puede detectar un porcentaje mucho mayor de errores?
Dado que hay muchos errores que no se pueden detectar por medio del tipeo estático, sería irresponsable negarse a usar otros métodos de control de calidad como la revisión de código y TDD. Por lo tanto, es injusto confiar en el hecho de que TypeScript será la única herramienta de algún proyecto utilizado para tratar errores. Para percibir de manera realista el indicador considerado de nuestro análisis de la efectividad de TypeScript, vale la pena calcular el número potencial de errores detectados por TypeScript, después de que los errores detectados por otros métodos se excluyan de su número.
Suponga que su proyecto contendría 1000 errores si no tomara ninguna medida para tratar los errores. Después de que el proyecto se haya probado correctamente, el número potencial de errores que pueden alcanzar la producción se ha reducido a 100. Ahora, para ver las posibilidades reales de TypeScript, veamos cuántos de estos errores se pueden detectar al usarlo. Dado que aproximadamente el 80% de los errores no se pueden detectar con TypeScript, y teniendo en cuenta que, en teoría, todos los errores detectados con TypeScript se pueden detectar con otros métodos, como la metodología TDD, llegaremos con bastante generosidad y asumiremos que TypeScript detectará otro 8% de errores. Aquí, además, procedemos de la suposición de que no encontramos aproximadamente la mitad de los errores que TypeScript detecta de otras maneras. El resultado es el siguiente:
- Un proyecto en el que no se aplican medidas de control de errores contiene 1000 errores.
- Usando medidas para combatir errores que no son de TypeScript, se detectaron 900 errores.
- Después de verificar el proyecto usando TypeScript, quedaron 92 errores. Esto significa que gracias a la implementación de TypeScript, se detectaron otros 8 errores.
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
▍ JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
▍ (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
▍ , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
▍ (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
▍ (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
▍ , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
TypeScript, , , , — , , TypeScript. TypeScript . , — , , TypeScript.
.
TypeScript , «JavaScript, ». : «JavaScript, ».
! TypeScript.
