¿Presentamos la seguridad de tipos en su proyecto de JavaScript? Piensa otra vez

¿Presentamos la seguridad de tipos en su proyecto de JavaScript? Piensa otra vez

Actualización - 1 de febrero de 2017

He escuchado varios contraargumentos con respecto a la seguridad de tipos en JavaScript desde que publiqué este artículo por primera vez, y aunque todavía creo que muchos proyectos no requieren el uso de un superconjunto de JavaScript escrito, admito que fui demasiado apresurado al publicar esto. artículo. Posteriormente, algunos casos de uso apropiados me han llamado la atención:

  • Glimmer, el motor de renderizado de bajo nivel detrás de Ember, está escrito en TypeScript para promover sitios de llamadas monomórficas, lo que ayuda al rendimiento cuando se ejecuta con V8 y potencialmente con otros motores JavaScript.
  • Visual Studio Code se beneficia de TypeScript debido al gran tamaño del proyecto; dado que se distribuye como una aplicación de escritorio, tener una base de código en lugar de reconciliar paquetes individuales en el momento de la compilación es, en mi opinión, una opción sensata
  • Sect (es cierto que es un proyecto propio, ¡así que hay un sesgo potencial aquí!) Está escrito en TypeScript para que los consumidores puedan escribir juegos modulares grandes para la web mientras reducen de manera confiable los errores de tiempo de ejecución resultantes de errores ortográficos y otros problemas que surgen como resultado de JavaScript naturaleza dinámica

Además, me he dado cuenta de que escribir bibliotecas más pequeñas en TypeScript y publicarlas con las definiciones de tipo generadas en el momento de la compilación permite su integración perfecta con proyectos de JavaScript tradicionales y mecanografiados , lo que brinda a los desarrolladores una opción tecnológica más amplia.

No obstante, por el bien de la posteridad, aquí está el artículo original en su totalidad.

Hoy, encontré un artículo sobre el lanzamiento de JS ++, que afirma "solucionar la falta de seguridad de tipos de JavaScript". Curiosamente, ya tenemos TypeScript, ST-JS y Scala.js, que ayudan a los desarrolladores a lograr el mismo objetivo.

Antes de lanzarme a esta diatriba, permítame resaltar tres puntos importantes:

  • Anteriormente escribí un tutorial sobre cómo establecer un proyecto de TypeScript simple. Veo la hipocresía pero mis opiniones han cambiado desde que lo publiqué hace más de un año
  • La escritura fuerte y la escritura estática son paradigmas vitales. El primero proporciona transparencia sobre las entidades representadas en el código de uno, sus relaciones y la funcionalidad que se espera que proporcionen, mientras que el segundo es una red de seguridad importante en tiempo de compilación en sistemas complejos. Vengo de un fondo de C #, así que tengo experiencia de primera mano de esto
  • También me encanta JavaScript, dados sus defectos inherentes, muchos de los cuales se han solucionado con ECMAScript 6 y 7.

Entonces, ¿por qué estoy generalmente en contra de la escritura estática en JavaScript?

Principalmente, lo que hace que JavaScript sea un lenguaje tan poderoso es su naturaleza de tipo débil; es trivial implementar ramas de lógica a través de la coerción de tipos, y es muy fácil crear instancias de objetos de un tipo arbitrario. Además, la falta de compilación (a menos que se esté utilizando un transpilador o una herramienta de compilación como Babel, por ejemplo) hace que el desarrollo sea increíblemente rápido, siempre que el código no dé lugar a comportamientos extraños. En mi opinión, esto es lo que lo hace tan poderoso para el desarrollo frontend y backend simple (por ejemplo, IoT).

Personalmente, creo que si uno está desarrollando un sistema tan complejo que requiere seguridad de tipos, entonces debe usar un lenguaje que lo soporte en su núcleo; escribir un sistema de guía, que implica operaciones matemáticas complejas, en JavaScript es una locura.

Mi principal preocupación con estas herramientas y superconjuntos de JavaScript es que se compilan en, bueno, JavaScript; En consecuencia, estos programas se ejecutan en un contexto dinámico, por lo que podrían producirse los mismos efectos secundarios. TypeScript, por ejemplo, se puede escribir de forma estática (es decir, la información de tipos se recopila y analiza en tiempo de compilación), pero uno debe tener plena confianza en que el código resultante seguirá funcionando como se esperaba. Sí, por supuesto, incluso los lenguajes de tipado estático se compilan generalmente en un lenguaje de nivel inferior, que luego se suele interpretar, pero estos lenguajes de destino seguramente se diseñaron con mecanografía como un ciudadano de primera clase; como ejemplo, el compilador JIT de Microsoft para .NET aún implementa la verificación de tipos en tiempo de ejecución de su lenguaje intermedio antes de compilar en código nativo.

Además, cuando llevo a cabo el desarrollo de frontend, sigo pensando que JavaScript debe usarse para complementar las soluciones HTML y CSS, por ejemplo, agregar clases a elementos, realizar llamadas HTTP a servicios de backend, etc. Aplicaciones más grandes basadas en UI (para su información, también he escrito aplicaciones más grandes con React.js y Vanilla JS; me encantan las dos), prefiero mantener mi JS lo más ligero posible. Entiendo que esto no siempre es una posibilidad en la realidad, pero si los sistemas back-end sirven como la verdad de origen para la lógica empresarial fundamental, entonces el código frontend se vuelve más liviano y menos redundante; en este sentido, ¿qué beneficios traerá un sistema de tipos?

Siguiendo mi punto del tamaño del software frontend, mi trabajo actual implica escribir aplicaciones web concentradas para cada preocupación del sistema general; a diferencia de una gran aplicación de una sola página para nuestra tienda, que contiene una vista de lista de productos, una vista de detalles del producto y una vista de viaje de compra, tenemos las respectivas aplicaciones respaldadas por Node.js para ellos. Evidentemente, esta es una mejor práctica en términos de acoplamiento flexible y resiliencia, pero desde el punto de vista del código, permite enfocarse más fácilmente en la implementación de un área de nuestra interfaz.

Mi argumento final es este; ¿Es JavaScript realmente tan difícil de aprender? Como dije antes, ECMAScript 5 en sí mismo es un lenguaje defectuoso; los diferentes patrones de invocación de funciones y cómo afectan a la palabra clave `this` y la falta de alcance de bloques, por ejemplo, pueden dificultar las cosas para los principiantes. Sin embargo, con ECMAScript 6, además de la gran cantidad de recursos asombrosos que existen, es fácil de superar y estar al tanto de estos problemas. ¿Por qué no simplemente omitir al intermediario y aprender el idioma directamente?

Terminaré diciendo que soy un fanático de todos los enfoques de mecanografía, pero algunos se adaptan a ciertos escenarios más que otros. Si JavaScript funciona mejor para la mayoría del software frontend, dada su ubicuidad dentro de los equipos de desarrollo y sus proyectos, entonces seguramente no necesita un superconjunto. Además, hay una gran cantidad de idiomas que son intrínsecamente seguros, ¡así que deja de reinventar la rueda!